[PATCH v2] improve git svn performance

[manjian2006]

From: manjian2006 


* perl/Git/SVN.pm
  Modified according to Eric Wong 

>Hi, I'm interested in this.  How much did performance improve by
>(and how many revisions is the repository)>
Our svn server are built in a LAN,15152 revisions.Not optimized git-svn used 10 
hours or more to accomplish,
while optimized one using only 3-4 hours.


According to some profiling data,_rev_list subroutine and rebuild subroutine 
are consuming a large proportion of time.
So I improve _rev_list's performance by memoize its results,and avoid 
subprocess invocation by memoize rebuild subroutine's key data.

Signed-off-by: manjian2006 
---
 perl/Git/SVN.pm | 41 ++---
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 5273ee8..dc7942b 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1599,6 +1599,7 @@ sub tie_for_persistent_memoization {
my %lookup_svn_merge_cache;
my %check_cherry_pick_cache;
my %has_no_changes_cache;
+   my %_rev_list_cache;
 
tie_for_persistent_memoization(\%lookup_svn_merge_cache,
"$cache_path/lookup_svn_merge");
@@ -1620,6 +1621,14 @@ sub tie_for_persistent_memoization {
SCALAR_CACHE => ['HASH' => \%has_no_changes_cache],
LIST_CACHE => 'FAULT',
;
+
+   tie_for_persistent_memoization(\%_rev_list_cache,
+   "$cache_path/_rev_list");
+   memoize '_rev_list',
+   SCALAR_CACHE => 'FAULT',
+   LIST_CACHE => ['HASH' => \%_rev_list_cache],
+   ;
+
}
 
sub unmemoize_svn_mergeinfo_functions {
@@ -1629,6 +1638,7 @@ sub tie_for_persistent_memoization {
Memoize::unmemoize 'lookup_svn_merge';
Memoize::unmemoize 'check_cherry_pick';
Memoize::unmemoize 'has_no_changes';
+   Memoize::unmemoize '_rev_list';
}
 
sub clear_memoized_mergeinfo_caches {
@@ -1959,11 +1969,25 @@ sub rebuild_from_rev_db {
unlink $path or croak "unlink: $!";
 }
 
+#define a global associate map to record rebuild status
+my %rebuild_status;
+#define a global associate map to record rebuild verify status
+my %rebuild_verify_status;
+
 sub rebuild {
my ($self) = @_;
my $map_path = $self->map_path;
my $partial = (-e $map_path && ! -z $map_path);
-   return unless ::verify_ref($self->refname.'^0');
+   my $verify_key = $self->refname.'^0';
+   if (! exists $rebuild_verify_status{$verify_key} || ! defined 
$rebuild_verify_status{$verify_key} ) {
+   my $verify_result = ::verify_ref($verify_key);
+   if ($verify_result) {
+   $rebuild_verify_status{$verify_key} = 1;
+   }
+   }
+   if (! exists $rebuild_verify_status{$verify_key}) {
+   return;
+   }
if (!$partial && ($self->use_svm_props || $self->no_metadata)) {
my $rev_db = $self->rev_db_path;
$self->rebuild_from_rev_db($rev_db);
@@ -1977,10 +2001,21 @@ sub rebuild {
print "Rebuilding $map_path ...\n" if (!$partial);
my ($base_rev, $head) = ($partial ? $self->rev_map_max_norebuild(1) :
(undef, undef));
+   my $key_value = ($head ? "$head.." : "") . $self->refname;
+   if (exists $rebuild_status{$key_value}) {
+   print "Done rebuilding $map_path\n" if (!$partial || !$head);
+   my $rev_db_path = $self->rev_db_path;
+   if (-f $self->rev_db_path) {
+   unlink $self->rev_db_path or croak "unlink: $!";
+   }
+   $self->unlink_rev_db_symlink;
+   return;
+   }
my ($log, $ctx) =
-   command_output_pipe(qw/rev-list --pretty=raw --reverse/,
-   ($head ? "$head.." : "") . $self->refname,
+   command_output_pipe(qw/rev-list --pretty=raw --reverse/,
+   $key_value, 
'--');
+   $rebuild_status{$key_value} = 1;
my $metadata_url = $self->metadata_url;
remove_username($metadata_url);
my $svn_uuid = $self->rewrite_uuid || $self->ra_uuid;
-- 
1.8.3.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 0/6] Make 'git help everyday' work -> relnotes

[Philip Oakley]

From: "Junio C Hamano" 

"Philip Oakley"  writes:


I already have a local patch that creates a stalenote.txt file, and
includes that in a "release-notes(7)" man page, but it still leaves
the actual release notes in a separate plain text file, linked from
the man page, rather than being right at hand, which is what I think
readers would expect.


Sorry, but I still do not get it.  If you have a script


Ah, no, it's not a script.

I had simply moved the content of the stalenotes section into its own 
file 'stalenotes.txt' which could then be included both within the 
git(1) section it came from, and a new release-notes(7) man page.


With that set up the Documentation/Makefile would generate the man 
pages, with their appropriate links, which can be accessed via the 'git 
help' command.


The big 'however' was that this would not actually include the latest 
release notes as literal text for immediate reading into the 
release-notes(7) man page, which would be my aim, and I think what 
Stefan had suggested as a preferred style.



 that reads
git.txt and extracts its stale-notes section to generate the source
to be processed into release-notes(7), why can't that script also
include the contents of the latest release notes inline into its
output?

My release notes are _not_ written to be compatible with/processable
by AsciiDoc (they are meant to be mere plain text)---perhaps you are
wondering if that would make it harder to maintain your script that
produces release-notes.txt?

Confused...


My thought was that the latest release note would be included as literal 
text, as noted above.
Like you say, it may need to be a script, but I was being cautious about 
what extra work that would entail for each release.






My other question would be to ask how you normally manage the 
up-issue

of the stalenotes, and when you would normally create that section in
git(1) as I didn't see any ifdef::stalenotes[] being defined anywhere
else.


I'm not sure if I am understanding the question right (up-issue?),
but it used to be that the preformatted and web-reachable manual
pages at k.org were processed with stalenotes defined (which by the
way was disabled with adaa3caf "Meta/dodoc.sh: adjust to the new
layout, 2011-11-15" on the todo branch), and 26cfcfbf "Add release
notes to the distribution., 2007-02-13" used that facility to
prepare something like this:



I hadn't looked back into that part of history. I was somehow expecting 
to see 'stalenotes' being defined somewhere in the current documenation 
preparation options, hence my question about when you would set 
'stalenotes'.


I'll have a look back at that to see how it was used back then.


   docs/git.html
   /git-cat-file.html
   ...
   docs/vX.Y.Z/git.html
   docs/vX.Y.Z/git-cat-file.html
   ...

where the "latest" one lived immediately underneath docs/*, while
older ones were in versioned subdirectories.



--
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: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

[Paul Mackerras]

On Tue, Jan 21, 2014 at 10:33:02AM -0500, Marc Branchaud wrote:
> On 13-12-18 11:04 AM, Marc Branchaud wrote:
> > Users often find that "next" and "prev" do the opposite of what they
> > expect.  For example, "next" moves to the next match down the list, but
> > that is almost always backwards in time.  Replacing the text with arrows
> > makes it clear where the buttons will take the user.
> 
> Any opinions on this, either way?
> 
> I've grown fond of the down/up arrows.  I find them much clearer than the
> current next/prev buttons.
> 
> My only niggle about this patch is that the buttons are much smaller,
> requiring a bit more precision clicking.  But the smaller buttons allow more
> room for other widgets.

I showed it to a few colleagues who use gitk a lot.  One was
indifferent, the others liked it, so I have applied it.

Thanks,
Paul.
--
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] gitk: Comply with XDG base directory specification

[Paul Mackerras]

On Tue, Jan 21, 2014 at 07:10:16PM +, Astril Hayato wrote:
> Write the gitk config data to $XDG_CONFIG_HOME/git/gitk 
> ($HOME/.config/git/gitk
> by default) in line with the XDG specification. This makes it consistent with
> git which also follows the spec.
> 
> If $HOME/.gitk already exists use that for backward compatibility, so only new
> installations are affected.
> 
> Signed-off-by: Astril Hayato 

Thanks, applied.

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

Anomalous AUTHOR and DOCUMENTATION sections in manpages

[Michael Haggerty]

I just noticed that there are exactly four Git manpages with an "AUTHOR"
section and five with a "DOCUMENTATION" section:

$ make doc
$ grep -nIE -e '^\.SH "DOCUMENTATION|AUTHOR"' Documentation/*.[0-9]
Documentation/git-column.1:80:.SH "AUTHOR"
Documentation/git-for-each-ref.1:272:.SH "AUTHOR"
Documentation/git-for-each-ref.1:275:.SH "DOCUMENTATION"
Documentation/git-http-backend.1:404:.SH "AUTHOR"
Documentation/git-http-backend.1:407:.SH "DOCUMENTATION"
Documentation/git-notes.1:395:.SH "AUTHOR"
Documentation/git-notes.1:398:.SH "DOCUMENTATION"
Documentation/git-remote-ext.1:133:.SH "DOCUMENTATION"
Documentation/git-remote-fd.1:71:.SH "DOCUMENTATION"

These sections are inconsistent with the other manpages and seem
superfluous in a project that has, on the one hand, a public history
and, on the other hand, hundreds of contributors.  Would the mentioned
authors (CCed) consent to the removal of these sections?

I don't want to step on any feet here.  If you want to keep these
sections, I have no objection.  But my guess is that people added them
in these few instances without realizing that these sections are not
commonly used in Git documentation.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Add cross-references between docs for for-each-ref and show-ref

[Michael Haggerty]

Add cross-references between the manpages for git-for-each-ref(1) and
git-show-ref(1).

Signed-off-by: Michael Haggerty 
---
There is a lot of overlap between the functionality of these two
commands.  It might be handy to give the user some hints about when to
use one command vs. the other, but honestly I don't have a gut feeling
for this myself.  Maybe long-term the commands should converge into
one?

 Documentation/git-for-each-ref.txt | 4 
 Documentation/git-show-ref.txt | 1 +
 2 files changed, 5 insertions(+)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index 94f5c46..d639abe 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -227,6 +227,10 @@ Documentation
 -
 Documentation by Junio C Hamano and the git-list .
 
+SEE ALSO
+
+linkgit:git-show-ref[1]
+
 GIT
 ---
 Part of the linkgit:git[1] suite
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index b0a309b..ffd1b03 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -175,6 +175,7 @@ FILES
 
 SEE ALSO
 
+linkgit:git-for-each-ref[1],
 linkgit:git-ls-remote[1],
 linkgit:git-update-ref[1],
 linkgit:gitrepository-layout[5]
-- 
1.8.5.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: Anomalous AUTHOR and DOCUMENTATION sections in manpages

[Duy Nguyen]

On Wed, Jan 22, 2014 at 6:22 PM, Michael Haggerty  wrote:
> These sections are inconsistent with the other manpages and seem
> superfluous in a project that has, on the one hand, a public history
> and, on the other hand, hundreds of contributors.  Would the mentioned
> authors (CCed) consent to the removal of these sections?

No problem from me.
-- 
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

Re: Anomalous AUTHOR and DOCUMENTATION sections in manpages

[Johan Herland]

On Wed, Jan 22, 2014 at 12:39 PM, Duy Nguyen  wrote:
> On Wed, Jan 22, 2014 at 6:22 PM, Michael Haggerty  
> wrote:
>> These sections are inconsistent with the other manpages and seem
>> superfluous in a project that has, on the one hand, a public history
>> and, on the other hand, hundreds of contributors.  Would the mentioned
>> authors (CCed) consent to the removal of these sections?
>
> No problem from me.

No problems here.


-- 
Johan Herland, 
www.herland.net
--
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: [ANNOUNCE] Git v1.9-rc0

[Javier Domingo Cansino]

Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?

Cheers

Javier Domingo Cansino

[1] Google Code download service change announcement:
http://google-opensource.blogspot.se/2013/05/a-change-to-google-code-download-service.html
[2] Google Code download section FAQ:
https://code.google.com/p/support/wiki/DownloadsFAQ
--
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

Conceptual Question for git usage ...

[John McIntyre]

Hi,
I want to install git onto my home network - in fact, truth be told,
it's already on my server, but I have some questions as to its
implementation.

First of all, my network.  At the 'centre' (practically, if not
logically) is my Mac.  I consider this my 'central repository' of
everything.  Mail, documents, blog posts etc.  Everything is on this
machine.  The Mac is backed up i) to an external drive with Time
Machine, ii) to my Linux server (more on that below) via rsync and
iii) to my personal Linux laptop which sits on 27/7 at work via rsync.

My server.  This is a Linux server runing CentOS 6.5, and working as a
webserver, fileserver, MySQL server, mail server (primary MX), and is
the 'public face' of my domain name.

Then there are two other Linux servers - one running MySQL
replication, and the other as a publically-accessible 'sandbox' on
which people whom I train can connect via a specific port, and mess
around, with no possibility that what they do will damage other parts
of the LAN.

So basically, what I'd like to do is this.  I want to write code,
write blg posts, write essays for university, whatever.  And I want to
use git to maintain revisions, but where do I store them?  Do I make
the Mac my hub?  I have a git client on there.  Do I make the server
my 'hub'?  If I make the server the 'hub', then won't rsync back-ups
from the Mac to the server wipe them out?

I confess that my preference would be to use the server, because I
occasionally bring the Linux laptop home from the office and use that,
and don't want to connect it to the Mac.

Anyway, basically .. that's it.  Any ideas would be appreciated.  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: Anomalous AUTHOR and DOCUMENTATION sections in manpages

[Johannes Schindelin]

Hi Michael,

On Wed, 22 Jan 2014, Michael Haggerty wrote:

> Would the mentioned authors (CCed) consent to the removal of these
> sections?

Fine by me!
Dscho

P.S.: Congrats on your new job!
--
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: Conceptual Question for git usage ...

[Andrew Keller]

On Jan 22, 2014, at 9:20 AM, John McIntyre  wrote:

> …
> 
> So basically, what I'd like to do is this.  I want to write code,
> write blg posts, write essays for university, whatever.  And I want to
> use git to maintain revisions, but where do I store them?  Do I make
> the Mac my hub?  I have a git client on there.  Do I make the server
> my 'hub'?  If I make the server the 'hub', then won't rsync back-ups
> from the Mac to the server wipe them out?
> 
> …

Git's degree of flexibility in what is considered "the server" is valuable 
here.  I advise that you simply try a configuration, and see how it works.  
It's easy to change where origin points later.

With that said, like you, I have a small ad-hoc setup of automated rsync 
backups between my various computers and servers, and I have found some 
characteristics useful:

* I have rsync saving backups into dedicated backup folders on the remote 
machines.  This eliminates ambiguity of what to back up (server A won't blow 
away server B's Documents folder, for example).

* Using a publicly accessible server has been useful.  I set up port forwarding 
to the machine, and set up a domain name pointing to the server.  In general, 
when I have Internet access, I can access the server that contains my 
repositories.  I always use the same domain name, even if I'm in the same room 
as the server.

Hope that helps,
Andrew

--
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: Conceptual Question for git usage ...

[John McIntyre]

Thank you for that, Andrew.

I'm going to follow your advice and just set up a test repository,
which won't be a disaster, if it gets damaged or erased.

I backup my /Users/john/Documents from my Mac to /home/john/Documents
on the Linux server.  Except for my mail directory, which comes from
$HOME/Library/Mail and lives on $HOME/.mac.mail.backup on the server.

2014/1/22 Andrew Keller :
> On Jan 22, 2014, at 9:20 AM, John McIntyre  wrote:
>
>> …
>>
>> So basically, what I'd like to do is this.  I want to write code,
>> write blg posts, write essays for university, whatever.  And I want to
>> use git to maintain revisions, but where do I store them?  Do I make
>> the Mac my hub?  I have a git client on there.  Do I make the server
>> my 'hub'?  If I make the server the 'hub', then won't rsync back-ups
>> from the Mac to the server wipe them out?
>>
>> …
>
> Git's degree of flexibility in what is considered "the server" is valuable 
> here.  I advise that you simply try a configuration, and see how it works.  
> It's easy to change where origin points later.
>
> With that said, like you, I have a small ad-hoc setup of automated rsync 
> backups between my various computers and servers, and I have found some 
> characteristics useful:
>
> * I have rsync saving backups into dedicated backup folders on the remote 
> machines.  This eliminates ambiguity of what to back up (server A won't blow 
> away server B's Documents folder, for example).
>
> * Using a publicly accessible server has been useful.  I set up port 
> forwarding to the machine, and set up a domain name pointing to the server.  
> In general, when I have Internet access, I can access the server that 
> contains my repositories.  I always use the same domain name, even if I'm in 
> the same room as the server.
>
> Hope that helps,
> Andrew
>
--
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: Workflow on git with 2 branch with specifc code

[Gordon Freeman]

On 01/22/2014 12:23 PM, Gordon Freeman wrote:

On 01/22/2014 12:16 PM, Gordon Freeman wrote:

Oh, sorry if i misunderstand you. My english is not so good.
it will be a pleasure if you could explain that.

I did some research about topic branchs, and get a lot of useful info 
of workflows on the way that you suggest.
I did a lot of tests from the info that i got, most of it from 
https://github.com/dchelimsky/rspec/wiki/topic-branches
what i got here from the site is pretty the same of what you wrote 
about i think. and the results are pretty good so far.
On the processes i did'nt loose any info, i got some conflicts but 
all of them easily solved.



2014/1/20, Gordon Freeman  wrote:
Oh, sorry if i misunderstand you. My english is not so good.
it will be a pleasure if you could explain that.
Tanks and sorry for you trouble so far.


2014/1/18 Jon Seymour 

Actually, it wasn't the rebasing I was going to explain, but
a good process for using rebase and preserving the history of
the original, integrated client branch after you have rebased
it. There are good ways and less good ways to do this.

jon.


On Sun, Jan 19, 2014 at 3:07 AM, Gordon Freeman
 wrote:

Hello!
Thx you all guys for the help. That's no need more
explanations here for rebases Jon.
I alredy do a lot of  this when i need to change configs
 of databases and domains and other things,
of my local branch to do some tests, so this is ok for me.
Seems that i just need some. some people organization here.
I will get that info that you guys provide to our devel
group and aply that.

Thaks you all for the help.

On 18/01/2014 01:30, Jon Seymour wrote:

On Sat, Jan 18, 2014 at 10:05 AM, brian m. carlson
 wrote:

On Fri, Jan 17, 2014 at 10:14:28AM -0200, Gordon
Freeman wrote:

Hello guys, im Gordon. I have a question
about workflow with git that i dont know if
im doing it right. I have 1 repo with 2
branchs the first is the master of the
project. the second is a branch copy of the
master but he need to have some specifc code
because is code for a client. so, every time
that i updade master i need to merge master
with client branch and it give me conflicts
of course that will hapen. Well if was just
me who work on this 2 branchs it will be easy
to fix the conflicts and let all work and
shine. But whe have here, 10 people woking on
master branch and some times code are lost on
merge and we need to look on commits to
search whats goin on. What i just asking here
is if its correct the workflow that i do. If
for some problem like this, the community
have a standard resolution. Or if what im
doing here is all wrong.

There are many correct workflows. I personally
use the workflow you've mentioned for the exact
same reason (customizations for a client), but
I'm the only developer on that repository.

I agree with Brian that there are many correct
workflows and which one you choose does depend on
details of the branches you are trying to manage.
Myself, I would tend to avoid a workflow in which you
continually merge from master into the client branch.
The reason is that once you have done this 20 times
or so it will become quite difficult to understand
how and why the client branch diverged from the
master branch. Yes, it is in the history, but
reasoning about diffs that cross merge points is just
hard. Assuming that there is not much actual
development on the client branch, but rather a
relatively small set of customizations to
configuration and things of that kind, then I would
tend to maintain the client changes as topic branch,
then maintain a client integration branch which
represents the merge between master and the client
topic branch. Changes that represent divergence of
the client from the master branch would be committed
to the client topic branch and then merged into the
client integration branch. Refreshes from

Re: [ANNOUNCE] Git v1.9-rc0

[Junio C Hamano]

Javier Domingo Cansino  writes:

> Will there be any change on how tarballs are distributed, taking into
> account that Google will be shutting down Google Code Downloads
> section[1][2]?

Aside from the obvious "we won't be able to use something that is no
longer offered"?  They are not the only download site even now, so...
--
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: [ANNOUNCE] Git v1.9-rc0

[Stefan Näwe]

Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
> Will there be any change on how tarballs are distributed, taking into
> account that Google will be shutting down Google Code Downloads
> section[1][2]?
> 

Am I missing something or what's wrong with this:

  https://github.com/gitster/git/archive/v1.9-rc0.tar.gz

or any

  https://github.com/gitster/git/archive/$TAG.tar.gz

??

(As long as Junio continues to push to github, of course)

Stefan
-- 

/dev/random says: Folks who think they know it all bug those of us who do
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
--
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: Anomalous AUTHOR and DOCUMENTATION sections in manpages

[Junio C Hamano]

Michael Haggerty  writes:

> I just noticed that there are exactly four Git manpages with an "AUTHOR"
> section and five with a "DOCUMENTATION" section:
>
> $ make doc
> $ grep -nIE -e '^\.SH "DOCUMENTATION|AUTHOR"' Documentation/*.[0-9]
> Documentation/git-column.1:80:.SH "AUTHOR"
> Documentation/git-for-each-ref.1:272:.SH "AUTHOR"
> Documentation/git-for-each-ref.1:275:.SH "DOCUMENTATION"
> Documentation/git-http-backend.1:404:.SH "AUTHOR"
> Documentation/git-http-backend.1:407:.SH "DOCUMENTATION"
> Documentation/git-notes.1:395:.SH "AUTHOR"
> Documentation/git-notes.1:398:.SH "DOCUMENTATION"
> Documentation/git-remote-ext.1:133:.SH "DOCUMENTATION"
> Documentation/git-remote-fd.1:71:.SH "DOCUMENTATION"
>
> These sections are inconsistent with the other manpages and seem
> superfluous in a project that has, on the one hand, a public history
> and, on the other hand, hundreds of contributors.

We decided at 48bb914e (doc: drop author/documentation sections from
most pages, 2011-03-11) to remove them for that exact reason.  I'd
be happy to see the one in for-each-ref under my name go.

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] Add cross-references between docs for for-each-ref and show-ref

[Junio C Hamano]

Michael Haggerty  writes:

> Add cross-references between the manpages for git-for-each-ref(1) and
> git-show-ref(1).
>
> Signed-off-by: Michael Haggerty 
> ---
> There is a lot of overlap between the functionality of these two
> commands.

Two differences I most often use (i.e. take advantage of) are:

 - The former is about showing 0 or more matching refs, and not
   matching anything is a perfectly normal condition, i.e.

   $ git for-each-ref refs/heads/no-such

   exits with status 0.  The latter can be used with --verify to
   check if one ref exists, on the other hand.

 - The former takes the match-from-left-to-right pattern (similar to
   the usual pathspec match), while the latter matches from the
   tail.

   $ git for-each-ref refs/heads/*  ;# only one-level names
   $ git for-each-ref refs/heads/** ;# catches both master and mh/path-max
   $ git show-ref master ;# refs/heads/master, refs/remotes/origin/master,...

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

libz and RHEL 5.9 compile of Git

[salmansheikh]

Hello,

I have a RHEL system that I am not the admin of. I needed to install git and
got the source. Everything is okay until I got to this point below. I
downloaded and installed the latest libz (1.2.8) but i installed it under a
local directory under my user name (i.e. /home/ssheikh/local). The problem
is that git only looks in the locations below. I even have that directory in
my $LD_LIBRARY_PATH. So, how can I force make to use that version of libz
and not the old one that came with this RHEL 5.9 distro?

[ssheikh@gs-560g3080090e git-1.8.3.4]$ make
LINK git-credential-store
/usr/bin/ld: skipping incompatible /lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: cannot find -lz
collect2: ld returned 1 exit status
make: *** [git-credential-store] Error 1




--
View this message in context: 
http://git.661346.n2.nabble.com/libz-and-RHEL-5-9-compile-of-Git-tp7602374.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] Git v1.9-rc0

[Junio C Hamano]

Stefan Näwe  writes:

> Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
>> Will there be any change on how tarballs are distributed, taking into
>> account that Google will be shutting down Google Code Downloads
>> section[1][2]?
>> 
>
> Am I missing something or what's wrong with this:
>
>   https://github.com/gitster/git/archive/v1.9-rc0.tar.gz
>
> or any
>
>   https://github.com/gitster/git/archive/$TAG.tar.gz
>
> ??

Do these consume CPU every time somebody asks for a tarball?  That
might be considered "wrong" depending on the view.
--
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] Makefile: Fix compilation of windows resource file

[Junio C Hamano]

Johannes Sixt  writes:

> [Cc Pat, who added git.rc]
>
> Am 1/22/2014 0:48, schrieb Junio C Hamano:
>> Ramsay Jones  writes:
>> 
 Note that I am merely guessing that "short-digit" version numbers
 are acceptable by now after seeing

 https://sourceware.org/ml/binutils/2012-07/msg00199.html
>>>
>>> Ah, nice find!
>>>
>>> I will test your patch (below) and let you know soon, but it looks
>>> good to me. (I can't test it tonight, unfortunately.)
>> 
>> One thing to note is that I don't know why the existing code dropped
>> the fourth digit from the maintenance series.
>
> I don't know either. But it does not really matter. When there are 4
> digits in the FILEVERSION and PRODUCTVERSION statements, then the user
> does not see them as-are, but, for example, 1.8.1283 for
> FILEVERSION 1,8,5,3 (1283 = 5*256+3). Therefore, I think that there is
> no point in providing 4 numbers, and the patch below should be
> sufficient.

Would that work well when we do 1.9.1, the first maintenance/bugfix
release for 1.9?

> diff --git a/Makefile b/Makefile
> index b4af1e2..99b2b89 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1773,7 +1773,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES
>  
>  git.res: git.rc GIT-VERSION-FILE
>   $(QUIET_RC)$(RC) \
> -   $(join -DMAJOR= -DMINOR= -DPATCH=, $(wordlist 1,3,$(subst -, ,$(subst 
> ., ,$(GIT_VERSION) \
> +   $(join -DMAJOR= -DMINOR=, $(wordlist 1,2,$(subst -, ,$(subst ., 
> ,$(GIT_VERSION) \
> -DGIT_VERSION="\\\"$(GIT_VERSION)\\\"" $< -o $@
>  
>  ifndef NO_PERL
> diff --git a/git.rc b/git.rc
> index bce6db9..33aafb7 100644
> --- a/git.rc
> +++ b/git.rc
> @@ -1,6 +1,6 @@
>  1 VERSIONINFO
> -FILEVERSION MAJOR,MINOR,PATCH,0
> -PRODUCTVERSION  MAJOR,MINOR,PATCH,0
> +FILEVERSION MAJOR,MINOR,0,0
> +PRODUCTVERSION  MAJOR,MINOR,0,0
>  BEGIN
>BLOCK "StringFileInfo"
>BEGIN
--
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: libz and RHEL 5.9 compile of Git

[Jonathan Nieder]

Hi,

salmansheikh wrote:

> I
> downloaded and installed the latest libz (1.2.8) but i installed it under a
> local directory under my user name (i.e. /home/ssheikh/local). The problem
> is that git only looks in the locations below. I even have that directory in
> my $LD_LIBRARY_PATH.

Confusingly, LD_LIBRARY_PATH is only used a run-time.  The build time
library path is just called LIBRARY_PATH.

You may also need to add your libz's include/ dir to CPATH.  See
http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html for more
details.

Hope that helps,
Jonathan
--
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] Makefile: Fix compilation of windows resource file

[Johannes Sixt]

Am 1/22/2014 17:12, schrieb Junio C Hamano:
> Johannes Sixt  writes:
> 
>> [Cc Pat, who added git.rc]
>>
>> Am 1/22/2014 0:48, schrieb Junio C Hamano:
>>> Ramsay Jones  writes:
>>>
> Note that I am merely guessing that "short-digit" version numbers
> are acceptable by now after seeing
>
> https://sourceware.org/ml/binutils/2012-07/msg00199.html

 Ah, nice find!

 I will test your patch (below) and let you know soon, but it looks
 good to me. (I can't test it tonight, unfortunately.)
>>>
>>> One thing to note is that I don't know why the existing code dropped
>>> the fourth digit from the maintenance series.
>>
>> I don't know either. But it does not really matter. When there are 4
>> digits in the FILEVERSION and PRODUCTVERSION statements, then the user
>> does not see them as-are, but, for example, 1.8.1283 for
>> FILEVERSION 1,8,5,3 (1283 = 5*256+3). Therefore, I think that there is

I just noticed that I'm wrong here: The user will see "1.8.5.3". But I
think it makes no difference. Read on.

>> no point in providing 4 numbers, and the patch below should be
>> sufficient.
> 
> Would that work well when we do 1.9.1, the first maintenance/bugfix
> release for 1.9?

Define "work well".

The numbers defined in {FILE,PRODUCT}VERSION statements are intended for
machine consumption and are always 4 positions (if the source contains
fewer, they are padded with zeros). They can be used by installers to
decide whether a file that already exists in the system should be
overwritten by a newer version.

Unfortunately, these numbers are visible when the user invokes Properties
from the context menu of git.exe in the file manager and then switches to
the "Version" tab. All 4 positions are always listed. Therefore, the user
will see "1.9.0.0" for the first release of the 1.9 series, which is
"wrong", because you will call "1.9", not "1.9.0.0", I assume.

With sufficient effort, we could achieve that version 1.9.1 is listed as
"1.9.1.0". That is still "wrong".

Since we can't get this display right, I suggest that we just punt (as per
my patch). That should work out nicely because we can fairly safely assume
that there are no installers around that look at these particular version
numbers.

BTW, that same "Version" tab will have another entry, called "Product
Version" later in the list. This one lists the string that we pass in
-DGIT_VERSION (see quoted context below). It is the truely correct version
that *users* should be interested in.

> 
>> diff --git a/Makefile b/Makefile
>> index b4af1e2..99b2b89 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1773,7 +1773,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES
>>  
>>  git.res: git.rc GIT-VERSION-FILE
>>  $(QUIET_RC)$(RC) \
>> -  $(join -DMAJOR= -DMINOR= -DPATCH=, $(wordlist 1,3,$(subst -, ,$(subst 
>> ., ,$(GIT_VERSION) \
>> +  $(join -DMAJOR= -DMINOR=, $(wordlist 1,2,$(subst -, ,$(subst ., 
>> ,$(GIT_VERSION) \
>>-DGIT_VERSION="\\\"$(GIT_VERSION)\\\"" $< -o $@
>>  
>>  ifndef NO_PERL
>> diff --git a/git.rc b/git.rc
>> index bce6db9..33aafb7 100644
>> --- a/git.rc
>> +++ b/git.rc
>> @@ -1,6 +1,6 @@
>>  1 VERSIONINFO
>> -FILEVERSION MAJOR,MINOR,PATCH,0
>> -PRODUCTVERSION  MAJOR,MINOR,PATCH,0
>> +FILEVERSION MAJOR,MINOR,0,0
>> +PRODUCTVERSION  MAJOR,MINOR,0,0
>>  BEGIN
>>BLOCK "StringFileInfo"
>>BEGIN
--
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: [ANNOUNCE] Git v1.9-rc0

[Vicent Martí]

On Wed, Jan 22, 2014 at 5:11 PM, Junio C Hamano  wrote:
> Stefan Näwe  writes:
>
>> Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
>>> Will there be any change on how tarballs are distributed, taking into
>>> account that Google will be shutting down Google Code Downloads
>>> section[1][2]?
>>>
>>
>> Am I missing something or what's wrong with this:
>>
>>   https://github.com/gitster/git/archive/v1.9-rc0.tar.gz
>>
>> or any
>>
>>   https://github.com/gitster/git/archive/$TAG.tar.gz
>>
>> ??
>
> Do these consume CPU every time somebody asks for a tarball?  That
> might be considered "wrong" depending on the view.

No, our infrastructure caches frequently requested tarballs so they
don't have to be regenerated on the fly. If you would prefer to
distribute a different version of the tarball for the release (e.g.
one with a different filename or folder structure), you can upload it
directly to the release page of the tag:

https://github.com/gitster/git/releases/tag/v1.9-rc0

We'll automatically mirror your release to S3 and serve it from there.
You can also go ahead and edit the release page with the changelog
you've posted in this email thread to make it more user friendly.

WE WILL SERVE YOUR RELEASES, JUNIO

BECAUSE WE LOVE YOU

-vmg
--
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] Makefile: Fix compilation of windows resource file

[Junio C Hamano]

Johannes Sixt  writes:

> The numbers defined in {FILE,PRODUCT}VERSION statements are intended for
> machine consumption and are always 4 positions (if the source contains
> fewer, they are padded with zeros). They can be used by installers to
> decide whether a file that already exists in the system should be
> overwritten by a newer version.

OK, that makes sense.  If you package 1.9 (padded as 1.9.0.0) and
then 1.9.1 (padded as 1.9.1.0), you can update from 1.9 to 1.9.1
just fine.

> Unfortunately, these numbers are visible when the user invokes Properties
> from the context menu of git.exe in the file manager and then switches to
> the "Version" tab. All 4 positions are always listed. Therefore, the user
> will see "1.9.0.0" for the first release of the 1.9 series, which is
> "wrong", because you will call "1.9", not "1.9.0.0", I assume.
>
> With sufficient effort, we could achieve that version 1.9.1 is listed as
> "1.9.1.0". That is still "wrong".

I would not be worried about showing 1.9.1.0 for 1.9.1 and/or
1.9.0.0 for 1.9 at all.

But if the (receiving) system expects these to be monotonically
increasing, I suspect the script I posted would not "work well"
under that expectation.  When you package 1.9.2.g43218765.dirty,
that would become "1.9.2.0", and become indistinguishable from the
package taken from v1.9.2 tag, which is not good at all.  So the
script should strip [0-9]*\.g[0-9a-f]*\(\.dirty\)? from the end
first.

But even without complications from the "N-commit after the tag" it
won't "work well" if you cut packages from anything that is not
tagged anyway.  The only thing we know about any package taken from
the tip of 'master' past v1.9 is that it is newer than the package
taken from v1.9 tag. Sometimes it should be considered newer than a
package taken from v1.9.x tag (i.e. the contents of the maintenance
relase is fully included in 'master'), but not always (i.e. the tip
of 'master' when the package was made may contain up to v1.9.3 but
v1.9.4 may be newer than that).

If you truncate down to only two, like your patch does, anything
past v1.9 and before v1.10 (or v2.0) would have 1.9.0.0 and that is
no worse than giving 1.9.3.0 for v1.9.3 and giving 1.9.0.0 for
anything based on 'master'.  Your user may have installed a package
made from v1.9.1 and would want to update to the one taken from
'master' when it contained everything up to v1.9.3---under my
earlier "take numbers" approach, we would be "updating" from 1.9.1.0
to 1.9.0.0, which does not look like updating at all to the system.
The installers can use this to decide "a file that already exists in
the system" is newer, which is wrong, if I am reading your earlier
explanation corretly.

With your "we just take the first two numbers always", you would be
sidegrading between two 1.9.0.0, which may fare better.

> Since we can't get this display right, I suggest that we just punt (as per
> my patch). That should work out nicely because we can fairly safely assume
> that there are no installers around that look at these particular version
> numbers.
>
> BTW, that same "Version" tab will have another entry, called "Product
> Version" later in the list. This one lists the string that we pass in
> -DGIT_VERSION (see quoted context below). It is the truely correct version
> that *users* should be interested in.
>
>> 
>>> diff --git a/Makefile b/Makefile
>>> index b4af1e2..99b2b89 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1773,7 +1773,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES
>>>  
>>>  git.res: git.rc GIT-VERSION-FILE
>>> $(QUIET_RC)$(RC) \
>>> - $(join -DMAJOR= -DMINOR= -DPATCH=, $(wordlist 1,3,$(subst -, ,$(subst 
>>> ., ,$(GIT_VERSION) \
>>> + $(join -DMAJOR= -DMINOR=, $(wordlist 1,2,$(subst -, ,$(subst ., 
>>> ,$(GIT_VERSION) \
>>>   -DGIT_VERSION="\\\"$(GIT_VERSION)\\\"" $< -o $@
>>>  
>>>  ifndef NO_PERL
>>> diff --git a/git.rc b/git.rc
>>> index bce6db9..33aafb7 100644
>>> --- a/git.rc
>>> +++ b/git.rc
>>> @@ -1,6 +1,6 @@
>>>  1 VERSIONINFO
>>> -FILEVERSION MAJOR,MINOR,PATCH,0
>>> -PRODUCTVERSION  MAJOR,MINOR,PATCH,0
>>> +FILEVERSION MAJOR,MINOR,0,0
>>> +PRODUCTVERSION  MAJOR,MINOR,0,0
>>>  BEGIN
>>>BLOCK "StringFileInfo"
>>>BEGIN
--
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: [ANNOUNCE] Git v1.9-rc0

[Junio C Hamano]

Vicent Martí  writes:

>> Do these consume CPU every time somebody asks for a tarball?  That
>> might be considered "wrong" depending on the view.
>
> No, our infrastructure caches frequently requested tarballs so they
> don't have to be regenerated on the fly.

Thanks.  That is certainly good enough for consumers, and better
than having to manually create and upload for me ;-)
--
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: Problem importing from SVN repository with branches/tags at multiple levels using git-svn

[Robert Hancock]

On 01/15/2014 02:10 PM, Robert Hancock wrote:
> We have an SVN repository that has a structure for tags (likewise for
> branches) like this:
> 
> tags/tag1
> tags/tag2
> tags/tag3/
> tags/subdir/tag4
> tags/subdir/tag5
> 
> The idea is that I want to have git-svn import everything inside subdir
> as tags and everything else inside the root tags directory as tags, so I
> end up with tag1-tag5 in Git. I've got tags= entries like this in the
> Git configuration to try to achieve this:
> 
> tags = tags/subdir/*:refs/remotes/tags/*
> tags = tags/*:refs/remotes/tags/*
> 
> My expectation was that everything inside subdir would match the first
> line first and everything else would match the second line, so
> everything would work out OK. Unfortunately it seems like for the tags
> inside subdir, it's matching the second line and therefore trying to
> import everything in there as directories inside one tag called subdir.
> Changing the order of those lines doesn't seem to help either, it seems
> determined to try to match to tags/* regardless of what order the lines
> are in.
> 
> Clearly it would have been better if the repository had not been
> structured this way. However, rearranging it now won't help since the
> paths are like this in the SVN repository history.
> 
> The only solution I've found that kind of works is to use
> tags/{tag1,tag2,tag3} instead of tags/*. Unfortunately there are a ton
> of tags in that directory and adding in a giant list of tags there seems
> to slow down the import process a great deal. Also, there are
> potentially still tags being created in that root directory, so I would
> have to keep regenerating and updating this list in the Git
> configuration every time one was added. So this is not a good solution.
> It would be much easier if I could get a wildcard solution to work here.
> 
> Any thoughts?

Just to respond to my own question, it appears that the ignore-refs
configuration option allows one to deal with this situation. In this
case one would add something like:

ignore-refs = refs/remotes/tags/subdir$

to prevent git-svn from trying to create a Git ref called subdir.

Unfortunately there seems to be no documentation at all about this
option other than in the source commit which introduced it, unlike all
the other settings for git-svn - that seems like a bit of an oversight..

-- 
Robert Hancock
System Analyst
SED Systems
Email: hanc...@sedsystems.ca
--
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] pull: require choice between rebase/merge on non-fast-forward pull

[Flimm]

Has this patch been released yet?



--
View this message in context: 
http://git.661346.n2.nabble.com/first-parent-commit-graph-layout-and-pull-merge-direction-tp7586671p7602383.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Anomalous AUTHOR and DOCUMENTATION sections in manpages

[Shawn Pearce]

On Wed, Jan 22, 2014 at 3:22 AM, Michael Haggerty  wrote:
> I just noticed that there are exactly four Git manpages with an "AUTHOR"
> section and five with a "DOCUMENTATION" section:
>
> $ make doc
> $ grep -nIE -e '^\.SH "DOCUMENTATION|AUTHOR"' Documentation/*.[0-9]
> Documentation/git-column.1:80:.SH "AUTHOR"
> Documentation/git-for-each-ref.1:272:.SH "AUTHOR"
> Documentation/git-for-each-ref.1:275:.SH "DOCUMENTATION"
> Documentation/git-http-backend.1:404:.SH "AUTHOR"
> Documentation/git-http-backend.1:407:.SH "DOCUMENTATION"
> Documentation/git-notes.1:395:.SH "AUTHOR"
> Documentation/git-notes.1:398:.SH "DOCUMENTATION"
> Documentation/git-remote-ext.1:133:.SH "DOCUMENTATION"
> Documentation/git-remote-fd.1:71:.SH "DOCUMENTATION"
>
> These sections are inconsistent with the other manpages and seem
> superfluous in a project that has, on the one hand, a public history
> and, on the other hand, hundreds of contributors.  Would the mentioned
> authors (CCed) consent to the removal of these sections?

Fine by me, authorship is documented by history and blame anyway.  :-)
--
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] repack: accept larger window-memory and max-pack-size

[Junio C Hamano]

These quantities can be larger than an int.  Use ulong to express
them like the underlying pack-objects does, and also parse them with
the human-friendly unit suffixes.

Signed-off-by: Junio C Hamano 
---
 builtin/repack.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/builtin/repack.c b/builtin/repack.c
index a0ff5c7..8ce396b 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -130,9 +130,9 @@ int cmd_repack(int argc, const char **argv, const char 
*prefix)
int pack_everything = 0;
int delete_redundant = 0;
char *unpack_unreachable = NULL;
-   int window = 0, window_memory = 0;
+   int window = 0;
int depth = 0;
-   int max_pack_size = 0;
+   unsigned long max_pack_size = 0, window_memory = 0;
int no_reuse_delta = 0, no_reuse_object = 0;
int no_update_server_info = 0;
int quiet = 0;
@@ -159,11 +159,11 @@ int cmd_repack(int argc, const char **argv, const char 
*prefix)
N_("with -A, do not loosen objects older than 
this")),
OPT_INTEGER(0, "window", &window,
N_("size of the window used for delta 
compression")),
-   OPT_INTEGER(0, "window-memory", &window_memory,
+   OPT_HUM_ULONG(0, "window-memory", &window_memory,
N_("same as the above, but limit memory size 
instead of entries count")),
OPT_INTEGER(0, "depth", &depth,
N_("limits the maximum delta depth")),
-   OPT_INTEGER(0, "max-pack-size", &max_pack_size,
+   OPT_HUM_ULONG(0, "max-pack-size", &max_pack_size,
N_("maximum size of each packfile")),
OPT_END()
};
@@ -187,11 +187,11 @@ int cmd_repack(int argc, const char **argv, const char 
*prefix)
if (window)
argv_array_pushf(&cmd_args, "--window=%u", window);
if (window_memory)
-   argv_array_pushf(&cmd_args, "--window-memory=%u", 
window_memory);
+   argv_array_pushf(&cmd_args, "--window-memory=%lu", 
window_memory);
if (depth)
argv_array_pushf(&cmd_args, "--depth=%u", depth);
if (max_pack_size)
-   argv_array_pushf(&cmd_args, "--max_pack_size=%u", 
max_pack_size);
+   argv_array_pushf(&cmd_args, "--max_pack_size=%lu", 
max_pack_size);
if (no_reuse_delta)
argv_array_pushf(&cmd_args, "--no-reuse-delta");
if (no_reuse_object)
-- 
1.9-rc0-151-ga5225c0

--
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] parse-options: refactor human-friendly-integer parser out of pack-objects

[Junio C Hamano]

We only had code to understand unit suffixes such as g/m/k (as in
2g/400m/8k) in the configuration parser but not in the command line
option parser.  "git pack-objects" worked it around by having a
custom extension to the parse-options API; make it available to
other callers.

The new macro is not called OPT_ULONG() but OPT_HUM_ULONG(), as it
would be bizzarre to have ULONG that understands human friendly
units while INTEGER that does not.  It is not named with a shorter
"OPT_HULONG", primarily to avoid having to name a future parallel
for parsing human friendly integer "OPT_HINT".

Signed-off-by: Junio C Hamano 
---
 builtin/pack-objects.c | 25 -
 parse-options.c| 17 +
 parse-options.h|  5 +
 3 files changed, 26 insertions(+), 21 deletions(-)

diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index f069462..2fa8e1e 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2417,23 +2417,6 @@ static int option_parse_unpack_unreachable(const struct 
option *opt,
return 0;
 }
 
-static int option_parse_ulong(const struct option *opt,
- const char *arg, int unset)
-{
-   if (unset)
-   die(_("option %s does not accept negative form"),
-   opt->long_name);
-
-   if (!git_parse_ulong(arg, opt->value))
-   die(_("unable to parse value '%s' for option %s"),
-   arg, opt->long_name);
-   return 0;
-}
-
-#define OPT_ULONG(s, l, v, h) \
-   { OPTION_CALLBACK, (s), (l), (v), "n", (h), \
- PARSE_OPT_NONEG, option_parse_ulong }
-
 int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 {
int use_internal_rev_list = 0;
@@ -2455,16 +2438,16 @@ int cmd_pack_objects(int argc, const char **argv, const 
char *prefix)
{ OPTION_CALLBACK, 0, "index-version", NULL, 
N_("version[,offset]"),
  N_("write the pack index file in the specified idx format 
version"),
  0, option_parse_index_version },
-   OPT_ULONG(0, "max-pack-size", &pack_size_limit,
- N_("maximum size of each output pack file")),
+   OPT_HUM_ULONG(0, "max-pack-size", &pack_size_limit,
+ N_("maximum size of each output pack file")),
OPT_BOOL(0, "local", &local,
 N_("ignore borrowed objects from alternate object 
store")),
OPT_BOOL(0, "incremental", &incremental,
 N_("ignore packed objects")),
OPT_INTEGER(0, "window", &window,
N_("limit pack window by objects")),
-   OPT_ULONG(0, "window-memory", &window_memory_limit,
- N_("limit pack window by memory in addition to object 
limit")),
+   OPT_HUM_ULONG(0, "window-memory", &window_memory_limit,
+ N_("limit pack window by memory in addition to object 
limit")),
OPT_INTEGER(0, "depth", &depth,
N_("maximum length of delta chain allowed in the 
resulting pack")),
OPT_BOOL(0, "reuse-delta", &reuse_delta,
diff --git a/parse-options.c b/parse-options.c
index c2cbca2..948ade7 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -136,6 +136,23 @@ static int get_value(struct parse_opt_ctx_t *p,
return opterror(opt, "expects a numerical value", 
flags);
return 0;
 
+   case OPTION_ULONG:
+   if (unset) {
+   *(unsigned long *)opt->value = 0;
+   } else if (opt->flags & PARSE_OPT_OPTARG && !p->opt) {
+   *(unsigned long *)opt->value = opt->defval;
+   } else if (get_arg(p, opt, flags, &arg)) {
+   return -1;
+   } else if (opt->flags & PARSE_OPT_HUMAN_NUMBER) {
+   if (!git_parse_ulong(arg, (unsigned long *)opt->value))
+   return opterror(opt, "expects a numerical 
value", flags);
+   } else {
+   *(unsigned long *)opt->value = strtoul(arg, (char 
**)&s, 10);
+   if (*s)
+   return opterror(opt, "expects a numerical 
value", flags);
+   }
+   return 0;
+
default:
die("should not happen, someone must be hit on the forehead");
}
diff --git a/parse-options.h b/parse-options.h
index 9b94596..d65ecdb 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -16,6 +16,7 @@ enum parse_opt_type {
/* options with arguments (usually) */
OPTION_STRING,
OPTION_INTEGER,
+   OPTION_ULONG,
OPTION_CALLBACK,
OPTION_LOWLEVEL_CALLBACK,
OPTION_FILENAME
@@ -40,6 +41,7 @@ enum parse_opt_option_flags {
PARSE_OPT_LASTARG_DEFAULT = 16,
PARSE_OPT_NODASH = 32,
PARSE_O

[PATCH v2 0/2] Fix "repack --window-memory=4g" regression in 1.8.4

[Junio C Hamano]

The command line parser was broken when the command was
reimplemented in C in two ways.  It incorrectly limited the value
range of window-memory and max-pack-size to "int", and also stopped
grokking the unit suffixes like 2g/400m/8k.

These two patches apply on top of 35c14176 (Reword repack
documentation to no longer state it's a script, 2013-10-19) and
later can be merged down to maint-1.8.4 track and upwards.

Junio C Hamano (2):
  parse-options: refactor human-friendly-integer parser out of pack-objects
  repack: accept larger window-memory and max-pack-size

 builtin/pack-objects.c | 25 -
 builtin/repack.c   | 12 ++--
 parse-options.c| 17 +
 parse-options.h|  5 +
 4 files changed, 32 insertions(+), 27 deletions(-)

-- 
1.9-rc0-151-ga5225c0

--
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: libz and RHEL 5.9 compile of Git

[Torsten Bögershausen]

On 2014-01-22 16.59, salmansheikh wrote:
> Hello,
> 
> I have a RHEL system that I am not the admin of. I needed to install git and
> got the source. Everything is okay until I got to this point below. I
> downloaded and installed the latest libz (1.2.8) but i installed it under a
> local directory under my user name (i.e. /home/ssheikh/local). The problem
> is that git only looks in the locations below. I even have that directory in
> my $LD_LIBRARY_PATH. So, how can I force make to use that version of libz
> and not the old one that came with this RHEL 5.9 distro?
> 
> [ssheikh@gs-560g3080090e git-1.8.3.4]$ make
> LINK git-credential-store
> /usr/bin/ld: skipping incompatible /lib/libz.so when searching for -lz
> /usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
> /usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
> /usr/bin/ld: cannot find -lz
> collect2: ld returned 1 exit status
> make: *** [git-credential-store] Error 1
> 
You need to tell the linker where to search for the library.
Please have a look at the Makefile:

ifdef ZLIB_PATH
BASIC_CFLAGS += -I$(ZLIB_PATH)/include
EXTLIBS += -L$(ZLIB_PATH)/$(lib) $(CC_LD_DYNPATH)$(ZLIB_PATH)/$(lib)
endif

--
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] Makefile: Fix compilation of windows resource file

[Junio C Hamano]

Junio C Hamano  writes:

> Johannes Sixt  writes:
> ...
>> ..., I suggest that we just punt (as per
>> my patch). That should work out nicely because we can fairly safely assume
>> that there are no installers around that look at these particular version
>> numbers.

OK.  I do not think we care too deeply about how a "forced to be
four dewey-decimal numbers" looks compared to 2 or 3 numbers in the
$(GIT_VERSION), as I think we always had that (non-)issue, but not
being able to compile is not very nice.

So can you, Pat or Ramsay send a tested patch with a proposed log
message?   Preferrably by -rc1 but I think the change is low impact
that it can be in -rc2, leaving -rc1 broken.

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: Anomalous AUTHOR and DOCUMENTATION sections in manpages

[Ilari Liusvaara]

On Wed, Jan 22, 2014 at 12:22:23PM +0100, Michael Haggerty wrote:
> I just noticed that there are exactly four Git manpages with an "AUTHOR"
> section and five with a "DOCUMENTATION" section:
> 
> These sections are inconsistent with the other manpages and seem
> superfluous in a project that has, on the one hand, a public history
> and, on the other hand, hundreds of contributors.  Would the mentioned
> authors (CCed) consent to the removal of these sections?
 
Sure (it has been copyedited a lot anyway).

-Ilari
--
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: [PATCHv2] gitk: Replace "next" and "prev" buttons with down and up arrows.

[Junio C Hamano]

Paul Mackerras  writes:

> On Tue, Jan 21, 2014 at 10:33:02AM -0500, Marc Branchaud wrote:
>> On 13-12-18 11:04 AM, Marc Branchaud wrote:
>> > Users often find that "next" and "prev" do the opposite of what they
>> > expect.  For example, "next" moves to the next match down the list, but
>> > that is almost always backwards in time.  Replacing the text with arrows
>> > makes it clear where the buttons will take the user.
>> 
>> Any opinions on this, either way?
>> 
>> I've grown fond of the down/up arrows.  I find them much clearer than the
>> current next/prev buttons.
>> 
>> My only niggle about this patch is that the buttons are much smaller,
>> requiring a bit more precision clicking.  But the smaller buttons allow more
>> room for other widgets.
>
> I showed it to a few colleagues who use gitk a lot.  One was
> indifferent, the others liked it, so I have applied it.
>
> Thanks,
> Paul.

Is this a good time for me to pull from you?  I see these on your
'master' branch.

8f86339 gitk: Comply with XDG base directory specification
786f15c gitk: Replace "next" and "prev" buttons with down and up arrows
c61f3a9 gitk: chmod +x po2msg.sh
6c626a0 gitk: Update copyright dates
45f884c gitk: Add Bulgarian translation (304t)
1f3c872 gitk: Fix mistype

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

[PATCH] t3030-merge-recursive: Test known breakage with empty work tree

[Brad King]

Add test cases that use 'merge-recursive' plumbing with a temporary
index and empty work tree.  Populate the index using 'read-tree' and
'update-index --ignore-missing --refresh' to prepare for merge without
actually checking all files out to disk.  Verify that each merge
produces its expected tree while displaying no error diagnostics.

This approach can be used to compute tree merges while checking out only
conflicting files to disk (which is useful for server-side scripts).
Prior to commit 5b448b85 (merge-recursive: When we detect we can skip an
update, actually skip it, 2011-08-11) this worked cleanly in all cases.
Since that commit, merge-recursive displays a diagnostic such as

 error: addinfo_cache failed for path 'e'

when "our" side has a rename (to 'e').  The diagnostic does not
influence the return code and the merge appears to succeed, but it
causes this test case to fail.

Signed-off-by: Brad King 
---
 t/t3030-merge-recursive.sh | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index 2f96100..b6d3ed0 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -257,6 +257,7 @@ test_expect_success 'setup 8' '
git add e &&
test_tick &&
git commit -m "rename a->e" &&
+   c7=$(git rev-parse --verify HEAD) &&
git checkout rename-ln &&
git mv a e &&
test_ln_s_add e a &&
@@ -517,6 +518,52 @@ test_expect_success 'reset and bind merge' '
 
 '
 
+test_expect_failure 'merge-recursive w/ empty work tree - ours has rename' '
+   (
+GIT_WORK_TREE="$PWD/ours-has-rename-work" &&
+export GIT_WORK_TREE &&
+GIT_INDEX_FILE="$PWD/ours-has-rename-index" &&
+export GIT_INDEX_FILE &&
+mkdir "$GIT_WORK_TREE" &&
+git read-tree -i -m $c7 &&
+git update-index --ignore-missing --refresh &&
+git merge-recursive $c0 -- $c7 $c3 &&
+git ls-files -s >actual-files
+   ) 2>actual-err &&
+   >expected-err &&
+   cat >expected-files <<-EOF &&
+   100644 $o3 0b/c
+   100644 $o0 0c
+   100644 $o0 0d/e
+   100644 $o0 0e
+   EOF
+   test_cmp expected-files actual-files &&
+   test_cmp expected-err actual-err
+'
+
+test_expect_success 'merge-recursive w/ empty work tree - theirs has rename' '
+   (
+GIT_WORK_TREE="$PWD/theirs-has-rename-work" &&
+export GIT_WORK_TREE &&
+GIT_INDEX_FILE="$PWD/theirs-has-rename-index" &&
+export GIT_INDEX_FILE &&
+mkdir "$GIT_WORK_TREE" &&
+git read-tree -i -m $c3 &&
+git update-index --ignore-missing --refresh &&
+git merge-recursive $c0 -- $c3 $c7 &&
+git ls-files -s >actual-files
+   ) 2>actual-err &&
+   >expected-err &&
+   cat >expected-files <<-EOF &&
+   100644 $o3 0b/c
+   100644 $o0 0c
+   100644 $o0 0d/e
+   100644 $o0 0e
+   EOF
+   test_cmp expected-files actual-files &&
+   test_cmp expected-err actual-err
+'
+
 test_expect_success 'merge removes empty directories' '
 
git reset --hard master &&
-- 
1.8.5.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 v2] improve git svn performance

[Eric Wong]

manjian2...@gmail.com wrote:
> * perl/Git/SVN.pm
>   Modified according to Eric Wong 
> 
> >Hi, I'm interested in this.  How much did performance improve by
> >(and how many revisions is the repository)>

> Our svn server are built in a LAN,15152 revisions.Not optimized
> git-svn used 10 hours or more to accomplish, while optimized one using
> only 3-4 hours.
> 
> According to some profiling data,_rev_list subroutine and rebuild
> subroutine are consuming a large proportion of time.  So I improve
> _rev_list's performance by memoize its results,and avoid subprocess
> invocation by memoize rebuild subroutine's key data.

Impressive!  Thanks for that info.

> Signed-off-by: manjian2006 

Real name is preferred by this project, I think.

A proper patch would start something like this:
---8<
From: Your Name 
Subject: git-svn: memoize _rev_list and rebuild

According to profile data, _rev_list and rebuild consume a large
portion of time.  Memoize the results of _rev_list and memoize
rebuild internals to avoid subprocess invocation.

When importing 15152 revisions on a LAN, time improved from 10
hours to 3-4 hours.

Signed-off-by: Your Name 
-- a few more comments below ---

>  sub rebuild {
>   my ($self) = @_;
>   my $map_path = $self->map_path;
>   my $partial = (-e $map_path && ! -z $map_path);
> - return unless ::verify_ref($self->refname.'^0');
> + my $verify_key = $self->refname.'^0';
> + if (! exists $rebuild_verify_status{$verify_key} || ! defined 
> $rebuild_verify_status{$verify_key} ) {

80 column wrap, please.

However, I think just having a single
"!$rebuild_verify_status{$verify_key}" check is enough, no need for
extra defined/exists checks for %rebuild_verify_status nor %rebuild_status.
Neither of them load untrusted data.

> - command_output_pipe(qw/rev-list --pretty=raw --reverse/,
> - ($head ? "$head.." : "") . $self->refname,
> + command_output_pipe(qw/rev-list --pretty=raw --reverse/,
> + $key_value, 

Please do not leave trailing whitespace.  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: problematic git log submodule-dir/

[Jens Lehmann]

Am 20.01.2014 19:25, schrieb Paweł Sikora:
> i've noticed that 'git log submodule-dir' and 'git log submodule-dir/'
> return different results (module's head changes vs. nothing). is it a bug?
> looks like a trailing slash is a problem for git-log.

I think this is a bug, and for example "git diff" has similar problems.
This is especially nasty as shell auto-completion adds the '/' at the
end.

Duy, without having looked into the code myself yet: is this something
that might be easily fixed by using PATHSPEC_STRIP_SUBMODULE_SLASH*?
--
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: [ANNOUNCE] Git v1.9-rc0

[Ken Moffat]

On Wed, Jan 22, 2014 at 10:10:18AM -0800, Junio C Hamano wrote:
> Vicent Martí  writes:
> 
> >> Do these consume CPU every time somebody asks for a tarball?  That
> >> might be considered "wrong" depending on the view.
> >
> > No, our infrastructure caches frequently requested tarballs so they
> > don't have to be regenerated on the fly.
> 
> Thanks.  That is certainly good enough for consumers, and better
> than having to manually create and upload for me ;-)

 Two questions: Does regenerating (e.g. if the tarball has dropped
out of the cache) change its sums (md5sum or similar) ?  In (beyond)
linuxfromscratch we use md5sums to verify that a tarball has not
changed.  Also, will there be links for manpages and htmldocs
tarballs ?

 I note that all of these *are* still available at googlecode for
the moment : https://code.google.com/p/git-core/downloads/list

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
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 3/4] Speed up is_git_command() by checking early for internal commands

[Sebastian Schuberth]

On 05.01.2014 14:42, Sebastian Schuberth wrote:


Since 2dce956 is_git_command() is a bit slow as it does file I/O in the
call to list_commands_in_dir(). Avoid the file I/O by adding an early
check for internal commands.


Considering the purpose of the series is it better to say "builtin" instead of 
"internal" in the commit message?


True, I'll fix this in a re-rool.


Sorry for not coming up with the re-roll until now, but lucky Junio has 
fixed this himself in c6127fa which already is on master.


--
Sebastian Schuberth
--
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: [ANNOUNCE] Git v1.9-rc0

[Junio C Hamano]

Ken Moffat  writes:

>  I note that all of these *are* still available at googlecode for
> the moment : https://code.google.com/p/git-core/downloads/list

As I said, Cgc is not the ony download site.  The end of

http://git-blame.blogspot.com/p/git-public-repositories.html

lists the two sites that currently have the material.  I may replace
Cgc with something else (and add it/them to the list), but in the
meantime I do not think k.org will go out of business in anytime
soon, so...




--
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 1/4] Consistently use the term "builtin" instead of "internal command"

[Sebastian Schuberth]

On 02.01.2014 22:05, Sebastian Schuberth wrote:


would just leave me wondering "I never claimed it was built-in; what's
going on?"  I think it would be simplest to keep it as

 $ git whatever
 fatal: cannot handle "whatever" internally

which at least makes it clear that this is a low-level error.


Right, I'll change this in a re-roll (using single-quotes for the command name).


Sorry for not coming up with the re-roll until now, and now it's too 
late to fixup the commit as it's already on master (3f784a4). Since this 
is just a minor wording issue I'll not follow this up anymore.


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

[RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

[Linus Torvalds]

From: Linus Torvalds 
Date: Wed, 22 Jan 2014 12:32:30 -0800
Subject: [PATCH] Make 'git request-pull' more strict about matching
 local/remote branches

The current 'request-pull' will try to find matching commit on the given 
remote, and rewrite the "please pull" line to match that remote ref.

That may be very helpful if your local tree doesn't match the layout of 
the remote branches, but for the common case it's been a recurring 
disaster, when "request-pull" is done against a delayed remote update, and 
it rewrites the target branch randomly to some other branch name that 
happens to have the same expected SHA1 (or more commonly, leaves it 
blank).

To avoid that recurring problem, this changes "git request-pull" so that 
it matches the ref name to be pulled against the *local* repository, and 
then warns if the remote repository does not have that exact same branch 
or tag name and content.

This means that git request-pull will never rewrite the ref-name you gave 
it.  If the local branch name is "xyzzy", that is the only branch name 
that request-pull will ask the other side to fetch.

If the remote has that branch under a different name, that's your problem 
and git request-pull will not try to fix it up (but git request-pull will 
warn about the fact that no exact matching branch is found, and you can 
edit the end result to then have the remote name you want if it doesn't 
match your local one).

The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").

Signed-off-by: Linus Torvalds 
---

This should fix the problem we've had multiple times with kernel 
maintainers, where "git request-pull" ends up leaving the target branch 
name blank, because people either forgot to push it, or (more commonly) 
people pushed it just before doing the pull request, and it hadn't 
actually had time to mirror out to the public site.

Now, git request-pull will *warn* about the fact that the matching ref 
isn't found on the remote (and the new matching code is stricter at that), 
but it will never try to re-write the branch name that it asks the other 
end to pull.

So if the remote branch doesn't exist, you'll get a warning, but the pull 
request will still have the branch you specified.

The whole checking thing is both simplified (removing more lines than it 
adds) and made more strict.

Comments? It passes the tests I put it through locally, but I did *not* 
make it pass the test-suite, since it very much does change the rules. 
Some of the test suite code literally tests for the old completely broken 
case (at least t5150, subtests 4 and 5).

Thus the RFC part. Because the currect git request-pull behavior has been 
horrible.

 git-request-pull.sh | 110 
 1 file changed, 43 insertions(+), 67 deletions(-)

diff --git a/git-request-pull.sh b/git-request-pull.sh
index fe21d5db631c..659a412155d8 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -35,20 +35,7 @@ do
shift
 done
 
-base=$1 url=$2 head=${3-HEAD} status=0 branch_name=
-
-headref=$(git symbolic-ref -q "$head")
-if git show-ref -q --verify "$headref"
-then
-   branch_name=${headref#refs/heads/}
-   if test "z$branch_name" = "z$headref" ||
-   ! git config "branch.$branch_name.description" >/dev/null
-   then
-   branch_name=
-   fi
-fi
-
-tag_name=$(git describe --exact "$head^0" 2>/dev/null)
+base=$1 url=$2 status=0
 
 test -n "$base" && test -n "$url" || usage
 
@@ -58,55 +45,68 @@ then
 die "fatal: Not a valid revision: $base"
 fi
 
+#
+# $3 must be a symbolic ref, a unique ref, or
+# a SHA object expression
+#
+head=$(git symbolic-ref -q "${3-HEAD}")
+head=${head:-$(git show-ref "${3-HEAD}" | cut -d' ' -f2)}
+head=${head:-$(git rev-parse --quiet --verify "$3")}
+
+# None of the above? Bad.
+test -z "$head" && die "fatal: Not a valid revision: $3"
+
+# This also verifies that the resulting head is unique:
+# "git show-ref" could have shown multiple matching refs..
 headrev=$(git rev-parse --verify --quiet "$head"^0)
-if test -z "$headrev"
+test -z "$headrev" && die "fatal: Ambiguous revision: $3"
+
+# Was it a branch with a description?
+branch_name=${head#refs/heads/}
+if test "z$branch_name" = "z$headref" ||
+   ! git config "branch.$branch_name.description" >/dev/null
 then
-die "fatal: Not a valid revision: $head"
+   branch_name=
 fi
 
+prettyhead=${head#refs/}
+prettyhead=${prettyhead#heads/}
+
 merge_base=$(git merge-base $baserev $headrev) ||
 die "fatal: No commits in common between $base and $head"
 
-# $head is the token given from the command line, and $tag_name, if
-# exists, is the tag we are going to show the commit information for.
-# If that tag exists at the remote and it points at the commit, use it.
-# Otherwise, if a branch with the same name as $head exists at the r

RE: Problem importing from SVN repository with branches/tags at multiple levels using git-svn

[Jim Garrison]

> -Original Message-
> Behalf Of Robert Hancock
> Sent: Wednesday, January 22, 2014 11:03 AM
> Subject: Re: Problem importing from SVN repository with branches/tags at
> multiple levels using git-svn
> 
> On 01/15/2014 02:10 PM, Robert Hancock wrote:
> > We have an SVN repository that has a structure for tags (likewise for
> > branches) like this:
> >
> > tags/tag1
> > tags/tag2
> > tags/tag3/
> > tags/subdir/tag4
> > tags/subdir/tag5
> >
[snip]

We did this recently and decided there is only one way to do it reliably.

Copy all the tags, within subversion itself, into the structure expected by 
git, then use git svn following the procedures outlined in the manual.

Copying tags is cheap in subversion, and you can always delete them afterwards 
if you want.

Re: libz and RHEL 5.9 compile of Git

[salmansheikh]

Got it working but then I had some issues with the perl portions of the
install and I subsequently thought I could eliminate those portions and
tried setting export NO_PERL=1 and that installed everything else...and got
pass this error but when I tried to checkout a git repository as follows, I
get some remote helper error. Is that related to the perl parts of the git? 

git clone https://github.com/m-labs/migen.git
Cloning into 'migen'...
fatal: Unable to find remote helper for 'https'


***
install -d -m 755 '/home/ssheikh/local/libexec/git-core'
install   git-credential-store git-daemon git-fast-import git-http-backend
git-imap-send git-sh-i18n--envsubst git-shell git-show-index git-upload-pack
git-remote-testsvn git-credential-cache git-credential-cache--daemon git-am
git-bisect git-difftool--helper git-filter-branch git-lost-found
git-merge-octopus git-merge-one-file git-merge-resolve git-mergetool
git-pull git-quiltimport git-rebase git-repack git-request-pull git-stash
git-submodule git-web--browse git-add--interactive git-difftool
git-archimport git-cvsexportcommit git-cvsimport git-cvsserver git-relink
git-send-email git-svn git-remote-testpy git-p4 git-instaweb
'/home/ssheikh/local/libexec/git-core'
install -m 644  git-mergetool--lib git-parse-remote git-rebase--am
git-rebase--interactive git-rebase--merge git-sh-setup git-sh-i18n
'/home/ssheikh/local/libexec/git-core'
install git git-upload-pack git-receive-pack git-upload-archive git-shell
git-cvsserver '/home/ssheikh/local/bin'
make -C templates DESTDIR='' install
make[1]: Entering directory `/home/ssheikh/Downloads/git-1.8.3.4/templates'
install -d -m 755 '/home/ssheikh/local/share/git-core/templates'
(cd blt && gtar cf - .) | \
(cd '/home/ssheikh/local/share/git-core/templates' && umask 022 &&
gtar xof -)
make[1]: Leaving directory `/home/ssheikh/Downloads/git-1.8.3.4/templates'
install -d -m 755 '/home/ssheikh/local/libexec/git-core/mergetools'
install -m 644 mergetools/*
'/home/ssheikh/local/libexec/git-core/mergetools'
install -d -m 755 '/home/ssheikh/local/share/locale'
(cd po/build/locale && gtar cf - .) | \
(cd '/home/ssheikh/local/share/locale' && umask 022 && gtar xof -)
make -C perl prefix='/home/ssheikh/local' DESTDIR='' install
make[1]: Entering directory `/home/ssheikh/Downloads/git-1.8.3.4/perl'
make[2]: Entering directory `/home/ssheikh/Downloads/git-1.8.3.4/perl'
mkdir /usr/local/lib64/perl5: Permission denied at
/usr/lib/perl5/5.8.8/ExtUtils/Install.pm line 112
make[2]: *** [pure_site_install] Error 13
make[2]: Leaving directory `/home/ssheikh/Downloads/git-1.8.3.4/perl'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/ssheikh/Downloads/git-1.8.3.4/perl'
make: *** [install] Error 2
*



--
View this message in context: 
http://git.661346.n2.nabble.com/libz-and-RHEL-5-9-compile-of-Git-tp7602374p7602400.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Anomalous AUTHOR and DOCUMENTATION sections in manpages

[Michael Haggerty]

On 01/22/2014 12:22 PM, Michael Haggerty wrote:
> I just noticed that there are exactly four Git manpages with an "AUTHOR"
> section and five with a "DOCUMENTATION" section:
> 
> $ make doc
> $ grep -nIE -e '^\.SH "DOCUMENTATION|AUTHOR"' Documentation/*.[0-9]
> Documentation/git-column.1:80:.SH "AUTHOR"
> Documentation/git-for-each-ref.1:272:.SH "AUTHOR"
> Documentation/git-for-each-ref.1:275:.SH "DOCUMENTATION"
> Documentation/git-http-backend.1:404:.SH "AUTHOR"
> Documentation/git-http-backend.1:407:.SH "DOCUMENTATION"
> Documentation/git-notes.1:395:.SH "AUTHOR"
> Documentation/git-notes.1:398:.SH "DOCUMENTATION"
> Documentation/git-remote-ext.1:133:.SH "DOCUMENTATION"
> Documentation/git-remote-fd.1:71:.SH "DOCUMENTATION"
> 
> These sections are inconsistent with the other manpages and seem
> superfluous in a project that has, on the one hand, a public history
> and, on the other hand, hundreds of contributors.  Would the mentioned
> authors (CCed) consent to the removal of these sections?
> 
> I don't want to step on any feet here.  If you want to keep these
> sections, I have no objection.  But my guess is that people added them
> in these few instances without realizing that these sections are not
> commonly used in Git documentation.

Thanks for the quick responses, everybody.  I'll prepare a patch.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

[Junio C Hamano]

Linus Torvalds  writes:

> This means that git request-pull will never rewrite the ref-name you gave 
> it.  If the local branch name is "xyzzy", that is the only branch name 
> that request-pull will ask the other side to fetch.
>
> If the remote has that branch under a different name, that's your problem 
> and git request-pull will not try to fix it up (but git request-pull will 
> warn about the fact that no exact matching branch is found, and you can 
> edit the end result to then have the remote name you want if it doesn't 
> match your local one).
>
> The new "find local ref" code will also complain loudly if you give an
> ambiguous refname (eg you have both a tag and a branch with that same
> name, and you don't specify "heads/name" or "tags/name").

I agree with the basic direction, especially the part "we will never
rewrite", is quite attractive.

But this part might be a bit problematic.  $3=master will almost
always have refs/heads/master and refs/remotes/origin/master listed
because the call to "show-ref" comes before "rev-parse --verify",
no?

> +head=$(git symbolic-ref -q "${3-HEAD}")
> +head=${head:-$(git show-ref "${3-HEAD}" | cut -d' ' -f2)}
> +head=${head:-$(git rev-parse --quiet --verify "$3")}
> +
> +# None of the above? Bad.
> +test -z "$head" && die "fatal: Not a valid revision: $3"
> +
> +# This also verifies that the resulting head is unique:
> +# "git show-ref" could have shown multiple matching refs..
>  headrev=$(git rev-parse --verify --quiet "$head"^0)
> -if test -z "$headrev"
> +test -z "$headrev" && die "fatal: Ambiguous revision: $3"

... and it would die here.  $3=for-linus may be the most common case
on the kernel list, and remotes/origin/for-linus may be unlikely to
appear in the real life (hmph, really?  perhaps people keep track of
what they pushed out the last time with it, I dunno).

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

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

[Linus Torvalds]

On Wed, Jan 22, 2014 at 1:46 PM, Junio C Hamano  wrote:
>>
>> The new "find local ref" code will also complain loudly if you give an
>> ambiguous refname (eg you have both a tag and a branch with that same
>> name, and you don't specify "heads/name" or "tags/name").
>
> But this part might be a bit problematic.  $3=master will almost
> always have refs/heads/master and refs/remotes/origin/master listed
> because the call to "show-ref" comes before "rev-parse --verify",
> no?

Hmm. Yes.

It's done that way very much on purpose, to avoid the branch/tag
ambiguity (which we have had problems with), but you're right, it also
ends up being ambiguous wrt remote branches, which wasn't the
intention, and you're right, that is not acceptable.

Damn. I very much want to get the full ref-name (ie "master" should
become "refs/heads/master"), and I do want to avoid the branch/tag
ambiguity, but you're right, "show-ref" plus the subsequent "rev-parse
--verify" comes close but not quite close enough.

Any ideas? The hacky way is to do "| head -1" to take the first
show-ref output, and then check if you get a different result if you
re-do it using "show-ref --tags". But that sounds really excessively
hacky. Is there a good way to do it?

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

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

[Linus Torvalds]

On Wed, Jan 22, 2014 at 2:03 PM, Linus Torvalds
 wrote:
>
> Any ideas? The hacky way is to do "| head -1" to take the first
> show-ref output, and then check if you get a different result if you
> re-do it using "show-ref --tags". But that sounds really excessively
> hacky. Is there a good way to do it?

Using "git show-refs --tags --heads" would work for the common case
(since that ignores remote branches), but would then disallow remote
branches entirely.

That might be ok in practice, but it's definitely wrong too.

I'm probably missing some obvious solution.

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

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

[Junio C Hamano]

Linus Torvalds  writes:

> That may be very helpful if your local tree doesn't match the layout of 
> the remote branches, but for the common case it's been a recurring 
> disaster, when "request-pull" is done against a delayed remote update, and 
> it rewrites the target branch randomly to some other branch name that 
> happens to have the same expected SHA1 (or more commonly, leaves it 
> blank).

Thinking about this a bit more...

> Comments? It passes the tests I put it through locally, but I did *not* 
> make it pass the test-suite, since it very much does change the rules. 
> Some of the test suite code literally tests for the old completely broken 
> case (at least t5150, subtests 4 and 5).

I looked at 5150.4 and found that what it attempts to do is halfway
sensible.  The contributor works on the local 'master' branch,
publishes the result to 'for-linus' in its 'origin' repository, and
asks his state to be pulled, with:

git push origin master:for-linus
git request-pull initial origin

The contributor could be more explicit in his request-pull and say 

git request-pull initial origin master

but there is no 'master' on the publishing repository in this case
(or even if there is, it does not match what is being pushed out),
and there is no 'for-linus' branch locally, so there is no way for
him to say

git request-pull initial origin for-linus

unless he creates it locally first.

I am starting to wonder if it is a better fix to check potentially
ambiguous cases (e.g. the publishing repository does have 'master'
that does not point at the commit local 'master' points at, and
'for-linus' that points at the same commit, and the user asks for
'master' to be pulled) or clearly broken cases (e.g. the user gave
something other than HEAD explicitly from the command line, but we
ended up computing blank) and die loudly, without breaking cases
this test tries to protect.

On the other hand, I tend to think what 5150.5 wants is convoluted
and expects a broken behaviour.  Its publishing repository has
'master' and 'for-upstream', and also has 'tags/full' that is an
annotated tag that points at the commit, runs request-pull with its
local 'master', and expects the resulting message to ask 'tags/full'
to be pulled.  If the contributor wants such a non-commit to be
pulled, I think it should be made more explicit, i.e., not with

git request-pull initial $origin_url

but with

git request-pull initial $origin_url tags/full

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

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

[Linus Torvalds]

On Wed, Jan 22, 2014 at 2:14 PM, Junio C Hamano  wrote:
>
> I looked at 5150.4 and found that what it attempts to do is halfway
> sensible.

I agree that it is "half-way sensible". The important bit being the HALF part.

The half part is why we have the semantics we have. There's no
question about that.

The problem is, the *other* half is pure and utter crap. The "half-way
sensible" solution then generates pure and utter garbage in the
"totally sensible" case.

And that's why I think it needs to be fixed. Not because the existing
behavior can never make sense in some circumstances, but because the
existing behavior can screw up really really badly in other (arguably
more common, and definitely real) circumstances.

For the kernel, the broken "missing branch name" situation has come up
pretty regularly. This is definitely not a one-time event, it's more
like "almost every merge window somebody gets screwed by this and I
have to guess what the branch name should have been".

I think that we could potentially do a "local:remote" syntax for that
half-way sensible case, so that if you do

   git push .. master:for-linus

then you have to do

   git request-pull .. master:for-linus

to match the fact that you renamed your local branch on the remote.

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

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

[Junio C Hamano]

Junio C Hamano  writes:

> ... there is no 'for-linus' branch locally, so there is no way for
> him to say
>
> git request-pull initial origin for-linus
>
> unless he creates it locally first.

In real life on the kernel list, for-linus may have to be a signed
tag, and pushed out 1-to-1 name mapping, so in that sense, "unless
he creates it locally first" may not be a problem.

I'd throw this into "No, this is not the only way to do so and there
are workarounds available if we suddenly tightened the rule and
broke those who relied on this behaviour. But this is not a less
good way compared to the alternative of creating the same-named ref
first, so we _are_ breaking people deliberately---is that worth the
safety for always-push-one-to-one people?" category.

I'd throw the other one (i.e. 5150.5) into "that is crazy enough
that a short apology in the Release Notes is sufficient before
breaking those who relied on that behaviour" category, on the other
hand ;-).
--
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 0/2] Fix "repack --window-memory=4g" regression in 1.8.4

[Stefan Beller]

On 22.01.2014 20:58, Junio C Hamano wrote:
> The command line parser was broken when the command was
> reimplemented in C in two ways.  It incorrectly limited the value
> range of window-memory and max-pack-size to "int", and also stopped
> grokking the unit suffixes like 2g/400m/8k.
> 
> These two patches apply on top of 35c14176 (Reword repack
> documentation to no longer state it's a script, 2013-10-19) and
> later can be merged down to maint-1.8.4 track and upwards.
> 
> Junio C Hamano (2):
>   parse-options: refactor human-friendly-integer parser out of pack-objects
>   repack: accept larger window-memory and max-pack-size
> 
>  builtin/pack-objects.c | 25 -
>  builtin/repack.c   | 12 ++--
>  parse-options.c| 17 +
>  parse-options.h|  5 +
>  4 files changed, 32 insertions(+), 27 deletions(-)
> 

I recall we had a discussion about parsing as the shell script
just passed them on without altering the argument, while the new
c implementation parses the numbers already before passing them on.

Junio,
thanks for such a quick patch. I'd currently have only little time
for open source contributions.

The patches seems reasonable to me.

Thanks,
Stefan
--
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 00/11] git p4 tests and a few bug fixes

[Pete Wyckoff]

gits...@pobox.com wrote on Tue, 21 Jan 2014 16:03 -0800:
> Pete Wyckoff  writes:
[..]
> > Patch 03 is a regression fix, found and narrowed down thanks to
> > much work by Damien Gérard.  But it is obscure enough that I'm
> > not proposing it for a maintenance release.
> 
> Thanks.
> 
> I am inclined to say that we should queue this on a fork from
> 'maint, merge the result to 'master' before 1.9-rc1 and ship the
> result as part of the upcoming release, and then possibly merging
> the topic to 1.8.5.x maintenance release after that.
> 
> This is primarily because I personally do not have p4 expertise to
> test or properly judge this (iow, you are the area maintainer, the
> authority), and I somehow have this feeling that parking in 'next'
> for extended period of time would not give meaningfully larger
> exposure to the code.
> 
> What do you think?
> 
> If you feel uneasy about such a fast-track, I wouldn't push it,
> though.

I think you're right that fast-track is the best choice, and low
risk.  The diffs came out identical, and it merges cleanly to
master, and passes all tests in both.

Thanks Eric for the commit message fixes too!

Here comes a v2 that is otherwise identical, but based on
origin/maint from a couple weeks ago.

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

[PATCHv2 01/11] git p4 test: wildcards are supported

[Pete Wyckoff]

Since 9d57c4a (git p4: implement view spec wildcards with "p4
where", 2013-08-30), all the wildcard types should be supported.
Change must-fail tests to mark that they now pass.

Signed-off-by: Pete Wyckoff 
---
 t/t9809-git-p4-client-view.sh | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/t/t9809-git-p4-client-view.sh b/t/t9809-git-p4-client-view.sh
index 77f6349..23a827f 100755
--- a/t/t9809-git-p4-client-view.sh
+++ b/t/t9809-git-p4-client-view.sh
@@ -76,28 +76,28 @@ test_expect_success 'init depot' '
 '
 
 # double % for printf
-test_expect_success 'unsupported view wildcard %%n' '
+test_expect_success 'view wildcard %%n' '
client_view "//depot/1/sub/... //client/sub/1/..." &&
test_when_finished cleanup_git &&
-   test_must_fail git p4 clone --use-client-spec --dest="$git" //depot
+   git p4 clone --use-client-spec --dest="$git" //depot
 '
 
-test_expect_success 'unsupported view wildcard *' '
+test_expect_success 'view wildcard *' '
client_view "//depot/*/bar/... //client/*/bar/..." &&
test_when_finished cleanup_git &&
-   test_must_fail git p4 clone --use-client-spec --dest="$git" //depot
+   git p4 clone --use-client-spec --dest="$git" //depot
 '
 
-test_expect_success 'wildcard ... only supported at end of spec 1' '
+test_expect_success 'wildcard ... in the middle' '
client_view "//depot/.../file11 //client/.../file11" &&
test_when_finished cleanup_git &&
-   test_must_fail git p4 clone --use-client-spec --dest="$git" //depot
+   git p4 clone --use-client-spec --dest="$git" //depot
 '
 
-test_expect_success 'wildcard ... only supported at end of spec 2' '
+test_expect_success 'wildcard ... in the middle and at the end' '
client_view "//depot/.../a/... //client/.../a/..." &&
test_when_finished cleanup_git &&
-   test_must_fail git p4 clone --use-client-spec --dest="$git" //depot
+   git p4 clone --use-client-spec --dest="$git" //depot
 '
 
 test_expect_success 'basic map' '
-- 
1.8.5.2.364.g6ac45cd

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

[PATCHv2 02/11] git p4 test: ensure p4 symlink parsing works

[Pete Wyckoff]

While this happens to work, there was no test to make sure
that the basic importing of a symlink from p4 to git functioned.

Add a simple test to create a symlink in p4 and import it into git,
then verify that the symlink exists and has the correct target.

Signed-off-by: Pete Wyckoff 
---
 t/t9802-git-p4-filetype.sh | 17 +
 1 file changed, 17 insertions(+)

diff --git a/t/t9802-git-p4-filetype.sh b/t/t9802-git-p4-filetype.sh
index a82744b..94d7be9 100755
--- a/t/t9802-git-p4-filetype.sh
+++ b/t/t9802-git-p4-filetype.sh
@@ -250,6 +250,23 @@ test_expect_success 'ignore apple' '
)
 '
 
+test_expect_success SYMLINKS 'create p4 symlink' '
+   cd "$cli" &&
+   ln -s symlink-target symlink &&
+   p4 add symlink &&
+   p4 submit -d "add symlink"
+'
+
+test_expect_success SYMLINKS 'ensure p4 symlink parsed correctly' '
+   test_when_finished cleanup_git &&
+   git p4 clone --dest="$git" //depot@all &&
+   (
+   cd "$git" &&
+   test -L symlink &&
+   test $(readlink symlink) = symlink-target
+   )
+'
+
 test_expect_success 'kill p4d' '
kill_p4d
 '
-- 
1.8.5.2.364.g6ac45cd

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

[PATCHv2 04/11] git p4 test: explicitly check p4 wildcard delete

[Pete Wyckoff]

There was no test where p4 deleted a file with a wildcard
character.  Make sure git p4 applies the wildcard decoding
properly when importing a delete that includes a wildcard.

Signed-off-by: Pete Wyckoff 
---
 t/t9812-git-p4-wildcards.sh | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/t/t9812-git-p4-wildcards.sh b/t/t9812-git-p4-wildcards.sh
index 6763325..f2ddbc5 100755
--- a/t/t9812-git-p4-wildcards.sh
+++ b/t/t9812-git-p4-wildcards.sh
@@ -161,6 +161,33 @@ test_expect_success 'wildcard files submit back to p4, 
delete' '
)
 '
 
+test_expect_success 'p4 deleted a wildcard file' '
+   (
+   cd "$cli" &&
+   echo "wild delete test" >wild@delete &&
+   p4 add -f wild@delete &&
+   p4 submit -d "add wild@delete"
+   ) &&
+   test_when_finished cleanup_git &&
+   git p4 clone --dest="$git" //depot &&
+   (
+   cd "$git" &&
+   test_path_is_file wild@delete
+   ) &&
+   (
+   cd "$cli" &&
+   # must use its encoded name
+   p4 delete wild%40delete &&
+   p4 submit -d "delete wild@delete"
+   ) &&
+   (
+   cd "$git" &&
+   git p4 sync &&
+   git merge --ff-only p4/master &&
+   test_path_is_missing wild@delete
+   )
+'
+
 test_expect_success 'kill p4d' '
kill_p4d
 '
-- 
1.8.5.2.364.g6ac45cd

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

[PATCHv2 03/11] git p4: work around p4 bug that causes empty symlinks

[Pete Wyckoff]

Damien Gérard highlights an interesting problem.  Some p4
repositories end up with symlinks that have an empty target.  It
is not possible to create this with current p4, but they do
indeed exist.

The effect in git p4 is that "p4 print" on the symlink returns an
empty string, confusing the curret symlink-handling code.

Such broken repositories cause problems in p4 as well, even with
no git involved.  In p4, syncing to a change that includes a
bogus symlink causes errors:

//depot/empty-symlink - updating /home/me/p4/empty-symlink
rename: /home/me/p4/empty-symlink: No such file or directory

and leaves no symlink.

In git, replicate the p4 behavior by ignoring these bad symlinks.
If, in a later p4 revision, the symlink happens to point to
something non-null, the symlink will be replaced properly.

Add a big test for all this too.

This happens to be a regression introduced by 1292df1 (git-p4:
Fix occasional truncation of symlink contents., 2013-08-08) and
appeared first in 1.8.5.  But it shows up only in p4
repositories of dubious character, so can wait for a proper
release.

Tested-by: Damien Gérard 
Signed-off-by: Pete Wyckoff 
---
 git-p4.py  |  9 ++-
 t/t9802-git-p4-filetype.sh | 66 ++
 2 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/git-p4.py b/git-p4.py
index 06a3cc6..3a20d15 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2075,7 +2075,14 @@ class P4Sync(Command, P4UserMap):
 # p4 print on a symlink sometimes contains "target\n";
 # if it does, remove the newline
 data = ''.join(contents)
-if data[-1] == '\n':
+if not data:
+# Some version of p4 allowed creating a symlink that pointed
+# to nothing.  This causes p4 errors when checking out such
+# a change, and errors here too.  Work around it by ignoring
+# the bad symlink; hopefully a future change fixes it.
+print "\nIgnoring empty symlink in %s" % file['depotFile']
+return
+elif data[-1] == '\n':
 contents = [data[:-1]]
 else:
 contents = [data]
diff --git a/t/t9802-git-p4-filetype.sh b/t/t9802-git-p4-filetype.sh
index 94d7be9..66d3fc9 100755
--- a/t/t9802-git-p4-filetype.sh
+++ b/t/t9802-git-p4-filetype.sh
@@ -267,6 +267,72 @@ test_expect_success SYMLINKS 'ensure p4 symlink parsed 
correctly' '
)
 '
 
+test_expect_success SYMLINKS 'empty symlink target' '
+   (
+   # first create the file as a file
+   cd "$cli" &&
+   >empty-symlink &&
+   p4 add empty-symlink &&
+   p4 submit -d "add empty-symlink as a file"
+   ) &&
+   (
+   # now change it to be a symlink to "target1"
+   cd "$cli" &&
+   p4 edit empty-symlink &&
+   p4 reopen -t symlink empty-symlink &&
+   rm empty-symlink &&
+   ln -s target1 empty-symlink &&
+   p4 add empty-symlink &&
+   p4 submit -d "make empty-symlink point to target1"
+   ) &&
+   (
+   # Hack the p4 depot to make the symlink point to nothing;
+   # this should not happen in reality, but shows up
+   # in p4 repos in the wild.
+   #
+   # The sed expression changes this:
+   # @@
+   # text
+   # @target1
+   # @
+   # to this:
+   # @@
+   # text
+   # @@
+   #
+   cd "$db/depot" &&
+   sed "/@target1/{; s/target1/@/; n; d; }" \
+   empty-symlink,v >empty-symlink,v.tmp &&
+   mv empty-symlink,v.tmp empty-symlink,v
+   ) &&
+   (
+   # Make sure symlink really is empty.  Asking
+   # p4 to sync here will make it generate errors.
+   cd "$cli" &&
+   p4 print -q //depot/empty-symlink#2 >out &&
+   test ! -s out
+   ) &&
+   test_when_finished cleanup_git &&
+
+   # make sure git p4 handles it without error
+   git p4 clone --dest="$git" //depot@all &&
+
+   # fix the symlink, make it point to "target2"
+   (
+   cd "$cli" &&
+   p4 open empty-symlink &&
+   rm empty-symlink &&
+   ln -s target2 empty-symlink &&
+   p4 submit -d "make empty-symlink point to target2"
+   ) &&
+   cleanup_git &&
+   git p4 clone --dest="$git" //depot@all &&
+   (
+   cd "$git" &&
+   test $(readlink empty-symlink) = target2
+   )
+'
+
 test_expect_success 'kill p4d' '
kill_p4d
 '
-- 
1.8.5.2.364.g6ac45cd

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org

[PATCHv2 05/11] git p4 test: is_cli_file_writeable succeeds

[Pete Wyckoff]

Commit e9df0f9 (git p4: cygwin p4 client does not mark read-only,
2013-01-26) fixed a problem with "test -w" on cygwin, but mistakenly
marked the new test as failing.  Fix this.

Signed-off-by: Pete Wyckoff 
---
 t/t9807-git-p4-submit.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t9807-git-p4-submit.sh b/t/t9807-git-p4-submit.sh
index 1fb7bc7..4caf36e 100755
--- a/t/t9807-git-p4-submit.sh
+++ b/t/t9807-git-p4-submit.sh
@@ -17,7 +17,7 @@ test_expect_success 'init depot' '
)
 '
 
-test_expect_failure 'is_cli_file_writeable function' '
+test_expect_success 'is_cli_file_writeable function' '
(
cd "$cli" &&
echo a >a &&
-- 
1.8.5.2.364.g6ac45cd

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

[PATCHv2 06/11] git p4 test: run as user "author"

[Pete Wyckoff]

The tests use aut...@example.com as the canonical submitter, but
he does not have an entry in the p4 users database.  This causes
the generated change description to complain that the git and p4
users disagree.  The complaint message is still valid, just isn't
useful in tests.  It was introduced in 848de9c (git-p4: warn if
git authorship won't be retained, 2011-05-13).

Fix t9813 to use @example.com instead of @localhost due to change
in p4_add_user().  Move the function into the git p4 test library
so author can be added at initialization time.

Signed-off-by: Pete Wyckoff 
---
 t/lib-git-p4.sh  | 15 ++-
 t/t9813-git-p4-preserve-users.sh | 38 ++
 2 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index ccd918e..4ff2bb1 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -47,9 +47,10 @@ P4DPORT=$((10669 + ($testid - $git_p4_test_start)))
 
 P4PORT=localhost:$P4DPORT
 P4CLIENT=client
+P4USER=author
 P4EDITOR=:
 unset P4CHARSET
-export P4PORT P4CLIENT P4EDITOR P4CHARSET
+export P4PORT P4CLIENT P4USER P4EDITOR P4CHARSET
 
 db="$TRASH_DIRECTORY/db"
 cli="$TRASH_DIRECTORY/cli"
@@ -96,12 +97,24 @@ start_p4d() {
return 1
fi
 
+   # build a p4 user so aut...@example.com has an entry
+   p4_add_user author
+
# build a client
client_view "//depot/... //client/..." &&
 
return 0
 }
 
+p4_add_user() {
+   name=$1 &&
+   p4 user -f -i <<-EOF
+   User: $name
+   Email: $n...@example.com
+   FullName: Dr. $name
+   EOF
+}
+
 kill_p4d() {
pid=$(cat "$pidfile")
# it had better exist for the first kill
diff --git a/t/t9813-git-p4-preserve-users.sh b/t/t9813-git-p4-preserve-users.sh
index f2e85e5..166b840 100755
--- a/t/t9813-git-p4-preserve-users.sh
+++ b/t/t9813-git-p4-preserve-users.sh
@@ -19,16 +19,6 @@ test_expect_success 'create files' '
)
 '
 
-p4_add_user() {
-   name=$1 fullname=$2 &&
-   p4 user -f -i <<-EOF &&
-   User: $name
-   Email: $name@localhost
-   FullName: $fullname
-   EOF
-   p4 passwd -P secret $name
-}
-
 p4_grant_admin() {
name=$1 &&
{
@@ -51,8 +41,8 @@ make_change_by_user() {
 
 # Test username support, submitting as user 'alice'
 test_expect_success 'preserve users' '
-   p4_add_user alice Alice &&
-   p4_add_user bob Bob &&
+   p4_add_user alice &&
+   p4_add_user bob &&
p4_grant_admin alice &&
git p4 clone --dest="$git" //depot &&
test_when_finished cleanup_git &&
@@ -60,8 +50,8 @@ test_expect_success 'preserve users' '
cd "$git" &&
echo "username: a change by alice" >>file1 &&
echo "username: a change by bob" >>file2 &&
-   git commit --author "Alice " -m "a change by 
alice" file1 &&
-   git commit --author "Bob " -m "a change by bob" 
file2 &&
+   git commit --author "Alice " -m "a change by 
alice" file1 &&
+   git commit --author "Bob " -m "a change by 
bob" file2 &&
git config git-p4.skipSubmitEditCheck true &&
P4EDITOR=touch P4USER=alice P4PASSWD=secret git p4 commit 
--preserve-user &&
p4_check_commit_author file1 alice &&
@@ -78,7 +68,7 @@ test_expect_success 'refuse to preserve users without perms' '
cd "$git" &&
git config git-p4.skipSubmitEditCheck true &&
echo "username-noperms: a change by alice" >>file1 &&
-   git commit --author "Alice " -m "perms: a 
change by alice" file1 &&
+   git commit --author "Alice " -m "perms: a 
change by alice" file1 &&
P4EDITOR=touch P4USER=bob P4PASSWD=secret &&
export P4EDITOR P4USER P4PASSWD &&
test_must_fail git p4 commit --preserve-user &&
@@ -94,9 +84,9 @@ test_expect_success 'preserve user where author is unknown to 
p4' '
cd "$git" &&
git config git-p4.skipSubmitEditCheck true &&
echo "username-bob: a change by bob" >>file1 &&
-   git commit --author "Bob " -m "preserve: a 
change by bob" file1 &&
+   git commit --author "Bob " -m "preserve: a 
change by bob" file1 &&
echo "username-unknown: a change by charlie" >>file1 &&
-   git commit --author "Charlie " -m "preserve: 
a change by charlie" file1 &&
+   git commit --author "Charlie " -m 
"preserve: a change by charlie" file1 &&
P4EDITOR=touch P4USER=alice P4PASSWD=secret &&
export P4EDITOR P4USER P4PASSWD &&
test_must_fail git p4 commit --preserve-user &&
@@ -121,24 +111,24 @@ test_expect_success 'not preserving user with mixed 
authorship' '
(
cd "$git" &&
git config git-p4.skipSubmitEditCheck true &&
-   p4_add_user derek Der

[PATCHv2 08/11] git p4: handle files with wildcards when doing RCS scrubbing

[Pete Wyckoff]

Commit 9d7d446 (git p4: submit files with wildcards, 2012-04-29)
fixed problems with handling files that had p4 wildcard
characters, like "@" and "*".  But it missed one case, that of
RCS keyword scrubbing, which uses "p4 fstat" to extract type
information.  Fix it by calling wildcard_encode() on the raw
filename.

Signed-off-by: Pete Wyckoff 
---
 git-p4.py   |  4 ++--
 t/t9812-git-p4-wildcards.sh | 23 +++
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/git-p4.py b/git-p4.py
index f0a327d..39a0fa0 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -310,8 +310,8 @@ def split_p4_type(p4type):
 #
 # return the raw p4 type of a file (text, text+ko, etc)
 #
-def p4_type(file):
-results = p4CmdList(["fstat", "-T", "headType", file])
+def p4_type(f):
+results = p4CmdList(["fstat", "-T", "headType", wildcard_encode(f)])
 return results[0]['headType']
 
 #
diff --git a/t/t9812-git-p4-wildcards.sh b/t/t9812-git-p4-wildcards.sh
index f2ddbc5..c7472cb 100755
--- a/t/t9812-git-p4-wildcards.sh
+++ b/t/t9812-git-p4-wildcards.sh
@@ -188,6 +188,29 @@ test_expect_success 'p4 deleted a wildcard file' '
)
 '
 
+test_expect_success 'wildcard files requiring keyword scrub' '
+   (
+   cd "$cli" &&
+   cat <<-\EOF >scrub@wild &&
+   $Id$
+   line2
+   EOF
+   p4 add -t text+k -f scrub@wild &&
+   p4 submit -d "scrub at wild"
+   ) &&
+   test_when_finished cleanup_git &&
+   git p4 clone --dest="$git" //depot &&
+   (
+   cd "$git" &&
+   git config git-p4.skipSubmitEdit true &&
+   git config git-p4.attemptRCSCleanup true &&
+   sed "s/^line2/line2 edit/" sc...@wild.tmp &&
+   mv -f sc...@wild.tmp scrub@wild &&
+   git commit -m "scrub at wild line2 edit" scrub@wild &&
+   git p4 submit
+   )
+'
+
 test_expect_success 'kill p4d' '
kill_p4d
 '
-- 
1.8.5.2.364.g6ac45cd

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

[PATCHv2 07/11] git p4 test: do not pollute /tmp

[Pete Wyckoff]

Generating the submit template for p4 uses tempfile.mkstemp(),
which by default puts files in /tmp.  For a test that fails,
possibly on purpose, this is not cleaned up.  Run with TMPDIR
pointing into the trash directory so the temp files go away
with the test results.

To do this required some other minor changes.  First, the editor
is launched using system(editor + " " + template_file), using
shell expansion to build the command string.  This doesn't work
if editor has a space in it.  And is generally unwise as it's
easy to fool the shell into doing extra work.  Exec the args
directly, without shell expansion.

Second, without shell expansion, the trick of "P4EDITOR=:" used
in the tests doesn't work.  Use a real command, true, as the
non-interactive editor for testing.

Signed-off-by: Pete Wyckoff 
---
 git-p4.py  | 2 +-
 t/lib-git-p4.sh| 8 +++-
 t/t9805-git-p4-skip-submit-edit.sh | 6 --
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/git-p4.py b/git-p4.py
index 3a20d15..f0a327d 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1220,7 +1220,7 @@ class P4Submit(Command, P4UserMap):
 editor = os.environ.get("P4EDITOR")
 else:
 editor = read_pipe("git var GIT_EDITOR").strip()
-system(editor + " " + template_file)
+system([editor, template_file])
 
 # If the file was not saved, prompt to see if this patch should
 # be skipped.  But skip this verification step if configured so.
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index 4ff2bb1..5aa8adc 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -48,7 +48,7 @@ P4DPORT=$((10669 + ($testid - $git_p4_test_start)))
 P4PORT=localhost:$P4DPORT
 P4CLIENT=client
 P4USER=author
-P4EDITOR=:
+P4EDITOR=true
 unset P4CHARSET
 export P4PORT P4CLIENT P4USER P4EDITOR P4CHARSET
 
@@ -57,6 +57,12 @@ cli="$TRASH_DIRECTORY/cli"
 git="$TRASH_DIRECTORY/git"
 pidfile="$TRASH_DIRECTORY/p4d.pid"
 
+# git p4 submit generates a temp file, which will
+# not get cleaned up if the submission fails.  Don't
+# clutter up /tmp on the test machine.
+TMPDIR="$TRASH_DIRECTORY"
+export TMPDIR
+
 start_p4d() {
mkdir -p "$db" "$cli" "$git" &&
rm -f "$pidfile" &&
diff --git a/t/t9805-git-p4-skip-submit-edit.sh 
b/t/t9805-git-p4-skip-submit-edit.sh
index ff2cc79..8931188 100755
--- a/t/t9805-git-p4-skip-submit-edit.sh
+++ b/t/t9805-git-p4-skip-submit-edit.sh
@@ -17,7 +17,7 @@ test_expect_success 'init depot' '
)
 '
 
-# this works because EDITOR is set to :
+# this works because P4EDITOR is set to true
 test_expect_success 'no config, unedited, say yes' '
git p4 clone --dest="$git" //depot &&
test_when_finished cleanup_git &&
@@ -90,7 +90,9 @@ test_expect_success 'no config, edited' '
cd "$git" &&
echo line >>file1 &&
git commit -a -m "change 5" &&
-   P4EDITOR="" EDITOR="\"$TRASH_DIRECTORY/ed.sh\"" git p4 submit &&
+   P4EDITOR="$TRASH_DIRECTORY/ed.sh" &&
+   export P4EDITOR &&
+   git p4 submit &&
p4 changes //depot/... >wc &&
test_line_count = 5 wc
)
-- 
1.8.5.2.364.g6ac45cd

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

[PATCHv2 10/11] git p4 test: examine behavior with locked (+l) files

[Pete Wyckoff]

The p4 server can enforce file locking, so that only one user
can edit a file at a time.  Git p4 is unable to submit changes
to locked files.  Currently it exits poorly.  Ideally it would
notice the locked condition and clean up nicely.

Add a bunch of tests that describe the problem, hoping that
fixes appear in the future.

Signed-off-by: Pete Wyckoff 
---
 t/t9816-git-p4-locked.sh | 145 +++
 1 file changed, 145 insertions(+)
 create mode 100755 t/t9816-git-p4-locked.sh

diff --git a/t/t9816-git-p4-locked.sh b/t/t9816-git-p4-locked.sh
new file mode 100755
index 000..e71e543
--- /dev/null
+++ b/t/t9816-git-p4-locked.sh
@@ -0,0 +1,145 @@
+#!/bin/sh
+
+test_description='git p4 locked file behavior'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+   start_p4d
+'
+
+# See
+# 
http://www.perforce.com/perforce/doc.current/manuals/p4sag/03_superuser.html#1088563
+# for suggestions on how to configure "sitewide pessimistic locking"
+# where only one person can have a file open for edit at a time.
+test_expect_success 'init depot' '
+   (
+   cd "$cli" &&
+   echo "TypeMap: +l //depot/..." | p4 typemap -i &&
+   echo file1 >file1 &&
+   p4 add file1 &&
+   p4 submit -d "add file1"
+   )
+'
+
+test_expect_success 'edit with lock not taken' '
+   test_when_finished cleanup_git &&
+   git p4 clone --dest="$git" //depot &&
+   (
+   cd "$git" &&
+   echo line2 >>file1 &&
+   git add file1 &&
+   git commit -m "line2 in file1" &&
+   git config git-p4.skipSubmitEdit true &&
+   git p4 submit
+   )
+'
+
+test_expect_failure 'add with lock not taken' '
+   test_when_finished cleanup_git &&
+   git p4 clone --dest="$git" //depot &&
+   (
+   cd "$git" &&
+   echo line1 >>add-lock-not-taken &&
+   git add file2 &&
+   git commit -m "add add-lock-not-taken" &&
+   git config git-p4.skipSubmitEdit true &&
+   git p4 submit --verbose
+   )
+'
+
+lock_in_another_client() {
+   # build a different client
+   cli2="$TRASH_DIRECTORY/cli2" &&
+   mkdir -p "$cli2" &&
+   test_when_finished "p4 client -f -d client2 && rm -rf \"$cli2\"" &&
+   (
+   cd "$cli2" &&
+   P4CLIENT=client2 &&
+   cli="$cli2" &&
+   client_view "//depot/... //client2/..." &&
+   p4 sync &&
+   p4 open file1
+   )
+}
+
+test_expect_failure 'edit with lock taken' '
+   lock_in_another_client &&
+   test_when_finished cleanup_git &&
+   test_when_finished "cd \"$cli\" && p4 sync -f file1" &&
+   git p4 clone --dest="$git" //depot &&
+   (
+   cd "$git" &&
+   echo line3 >>file1 &&
+   git add file1 &&
+   git commit -m "line3 in file1" &&
+   git config git-p4.skipSubmitEdit true &&
+   git p4 submit --verbose
+   )
+'
+
+test_expect_failure 'delete with lock taken' '
+   lock_in_another_client &&
+   test_when_finished cleanup_git &&
+   test_when_finished "cd \"$cli\" && p4 sync -f file1" &&
+   git p4 clone --dest="$git" //depot &&
+   (
+   cd "$git" &&
+   git rm file1 &&
+   git commit -m "delete file1" &&
+   git config git-p4.skipSubmitEdit true &&
+   git p4 submit --verbose
+   )
+'
+
+test_expect_failure 'chmod with lock taken' '
+   lock_in_another_client &&
+   test_when_finished cleanup_git &&
+   test_when_finished "cd \"$cli\" && p4 sync -f file1" &&
+   git p4 clone --dest="$git" //depot &&
+   (
+   cd "$git" &&
+   chmod +x file1 &&
+   git add file1 &&
+   git commit -m "chmod +x file1" &&
+   git config git-p4.skipSubmitEdit true &&
+   git p4 submit --verbose
+   )
+'
+
+test_expect_failure 'copy with lock taken' '
+   lock_in_another_client &&
+   test_when_finished cleanup_git &&
+   test_when_finished "cd \"$cli\" && p4 revert file2 && rm -f file2" &&
+   git p4 clone --dest="$git" //depot &&
+   (
+   cd "$git" &&
+   cp file1 file2 &&
+   git add file2 &&
+   git commit -m "cp file1 to file2" &&
+   git config git-p4.skipSubmitEdit true &&
+   git config git-p4.detectCopies true &&
+   git p4 submit --verbose
+   )
+'
+
+test_expect_failure 'move with lock taken' '
+   lock_in_another_client &&
+   test_when_finished cleanup_git &&
+   test_when_finished "cd \"$cli\" && p4 sync file1 && rm -f file2" &&
+   git p4 clone --dest="$git" //depot &&
+   (
+   cd "$git" &&
+   git mv file1 file2 &&
+   git commit -

[PATCHv2 09/11] git p4: fix an error message when "p4 where" fails

[Pete Wyckoff]

When "p4 where" fails, for whatever reason, the error message tries to
show an undefined variable.  This minor bug applies only when using a
client spec, and was introduced recently in 9d57c4a (git p4: implement
view spec wildcards with "p4 where", 2013-08-30).

Signed-off-by: Pete Wyckoff 
---
 git-p4.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-p4.py b/git-p4.py
index 39a0fa0..db43629 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1871,7 +1871,7 @@ class View(object):
 # assume error is "... file(s) not in client view"
 continue
 if "clientFile" not in res:
-die("No clientFile from 'p4 where %s'" % depot_path)
+die("No clientFile in 'p4 where' output")
 if "unmap" in res:
 # it will list all of them, but only one not unmap-ped
 continue
-- 
1.8.5.2.364.g6ac45cd

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

[PATCHv2 11/11] git p4 doc: use two-line style for options with multiple spellings

[Pete Wyckoff]

Thomas Rast noticed the docs have a mix of styles when
it comes to options with multiple spellings.  Standardize
the couple in git-p4.txt that are odd.

Instead of:
  -n, --dry-run::

Do this:
  -n::
  --dry-run::

See
http://thread.gmane.org/gmane.comp.version-control.git/219936/focus=219945

Signed-off-by: Pete Wyckoff 
---
 Documentation/git-p4.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 8cba16d..6ab5f94 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -168,7 +168,8 @@ All commands except clone accept these options.
 --git-dir ::
Set the 'GIT_DIR' environment variable.  See linkgit:git[1].
 
---verbose, -v::
+-v::
+--verbose::
Provide more progress information.
 
 Sync options
@@ -279,7 +280,8 @@ These options can be used to modify 'git p4 submit' 
behavior.
Export tags from Git as p4 labels. Tags found in Git are applied
to the perforce working directory.
 
---dry-run, -n::
+-n::
+--dry-run::
Show just what commits would be submitted to p4; do not change
state in Git or p4.
 
-- 
1.8.5.2.364.g6ac45cd

--
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: [ANNOUNCE] Git v1.9-rc0

[Ken Moffat]

On Wed, Jan 22, 2014 at 01:04:02PM -0800, Junio C Hamano wrote:
> Ken Moffat  writes:
> 
> >  I note that all of these *are* still available at googlecode for
> > the moment : https://code.google.com/p/git-core/downloads/list
> 
> As I said, Cgc is not the ony download site.  The end of
> 
> http://git-blame.blogspot.com/p/git-public-repositories.html
> 
> lists the two sites that currently have the material.  I may replace
> Cgc with something else (and add it/them to the list), but in the
> meantime I do not think k.org will go out of business in anytime
> soon, so...
> 
 OK, thanks for the pointer to
https://www.kernel.org/pub/software/scm/git/ for released tarballs.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
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

What's cooking in git.git (Jan 2014, #04; Wed, 22)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[Graduated to "master"]

* fp/submodule-checkout-mode (2014-01-07) 1 commit
  (merged to 'next' on 2014-01-10 at 647ba9b)
 + git-submodule.sh: 'checkout' is a valid update mode
 (this branch is used by wk/submodule-on-branch.)

 "submodule.*.update=checkout", when propagated from .gitmodules to
 .git/config, turned into a "submodule.*.update=none", which did not
 make much sense.


* nd/shallow-clone (2014-01-09) 31 commits
  (merged to 'next' on 2014-01-09 at 6608634)
 + t5537: fix incorrect expectation in test case 10
  (merged to 'next' on 2014-01-06 at 3dc7fab)
 + shallow: remove unused code
 + send-pack.c: mark a file-local function static
  (merged to 'next' on 2014-01-03 at a776065)
 + git-clone.txt: remove shallow clone limitations
 + prune: clean .git/shallow after pruning objects
 + clone: use git protocol for cloning shallow repo locally
 + send-pack: support pushing from a shallow clone via http
 + receive-pack: support pushing to a shallow clone via http
 + smart-http: support shallow fetch/clone
 + remote-curl: pass ref SHA-1 to fetch-pack as well
 + send-pack: support pushing to a shallow clone
 + receive-pack: allow pushes that update .git/shallow
 + connected.c: add new variant that runs with --shallow-file
 + add GIT_SHALLOW_FILE to propagate --shallow-file to subprocesses
 + receive/send-pack: support pushing from a shallow clone
 + receive-pack: reorder some code in unpack()
 + fetch: add --update-shallow to accept refs that update .git/shallow
 + upload-pack: make sure deepening preserves shallow roots
 + fetch: support fetching from a shallow repository
 + clone: support remote shallow repository
 + fetch-pack.h: one statement per bitfield declaration
 + fetch-pack.c: move shallow update code out of fetch_pack()
 + shallow.c: steps 6 and 7 to select new commits for .git/shallow
 + shallow.c: the 8 steps to select new commits for .git/shallow
 + shallow.c: extend setup_*_shallow() to accept extra shallow commits
 + connect.c: teach get_remote_heads to parse "shallow" lines
 + make the sender advertise shallow commits to the receiver
 + clone: prevent --reference to a shallow repository
 + send-pack: forbid pushing from a shallow repository
 + remote.h: replace struct extra_have_objects with struct sha1_array
 + transport.h: remove send_pack prototype, already defined in send-pack.h

 Fetching from a shallow-cloned repository used to be forbidden,
 primarily because the codepaths involved were not carefully vetted
 and we did not bother supporting such usage. This attempts to allow
 object transfer out of a shallow-cloned repository in a controlled
 way (i.e. the receiver become a shallow repository with truncated
 history).

--
[New Topics]

* jn/ignore-doc (2014-01-16) 1 commit
  (merged to 'next' on 2014-01-22 at a07ac63)
 + gitignore doc: add global gitignore to synopsis

 Explicitly list $HOME/.config/git/ignore as one of the places you
 can use to keep ignore patterns that depend on your personal choice
 of tools, e.g. *~ for Emacs users.

 Will merge to 'master'.


* rk/send-email-ssl-cert (2014-01-16) 1 commit
  (merged to 'next' on 2014-01-22 at 2fb13f2)
 + send-email: /etc/ssl/certs/ directory may not be usable as ca_path

 The "if /etc/ssl/certs/ directory exists, explicitly tell the
 library to use it as SSL_ca_path" blind-defaulting in "git
 send-email" broke platforms where /etc/ssl/certs/ directory exists,
 but it cannot used as SSL_ca_path (e.g. Fedora rawhide).  Fix it by
 not specifying any SSL_ca_path/SSL_ca_file but still asking for
 peer verification in such a case.

 Will merge to 'master'.


* ef/mingw-write (2014-01-17) 2 commits
  (merged to 'next' on 2014-01-22 at b9ddab2)
 + mingw: remove mingw_write
 + prefer xwrite instead of write

 Will merge to 'master'.


* jk/branch-at-publish-rebased (2014-01-17) 5 commits
 - t1507 (rev-parse-upstream): fix typo in test title
 - implement @{publish} shorthand
 - branch_get: provide per-branch pushremote pointers
 - branch_get: return early on error
 - sha1_name: refactor upstream_mark
 (this branch uses jk/interpret-branch-name-fix.)

 Give an easier access to the tracking branches from "other" side in
 a triangular workflow by introducing B@{publish} that works in a
 similar way to how B@{upstream} does.


* jk/color-for-more-pagers (2014-01-17) 4 commits
 - pager: disable colors for some known-bad configurations
 - DONOTMERGE: needs matching change to git-sh-setup
 - setup_pager: set MORE=R
 - setup_pager: refactor LESS/LV environment setting


* jk/diff-filespec-cleanup (2014-01-17) 5 commits
  (merged to

Re: problematic git log submodule-dir/

[Duy Nguyen]

On Thu, Jan 23, 2014 at 3:35 AM, Jens Lehmann  wrote:
> Am 20.01.2014 19:25, schrieb Paweł Sikora:
>> i've noticed that 'git log submodule-dir' and 'git log submodule-dir/'
>> return different results (module's head changes vs. nothing). is it a bug?
>> looks like a trailing slash is a problem for git-log.
>
> I think this is a bug, and for example "git diff" has similar problems.
> This is especially nasty as shell auto-completion adds the '/' at the
> end.
>
> Duy, without having looked into the code myself yet: is this something
> that might be easily fixed by using PATHSPEC_STRIP_SUBMODULE_SLASH*?

I think so. But I dislike those preprocessing because it looks
inefficient and the same change may be needed for other diff commands
as well. Maybe we can handle this at diff or log-tree.c level. Will
look further into it tonight.
-- 
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

[RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

[Linus Torvalds]

From: Linus Torvalds 
Date: Wed, 22 Jan 2014 15:23:48 -0800
Subject: [PATCH] Make request-pull able to take a refspec of form local:remote

This allows a user to say that a local branch has a different name on
the remote server, using the same syntax that "git push" uses to create
that situation.

Signed-off-by: Linus Torvalds 
---

So this relaxes the remote matching, and allows using the "local:remote" 
syntax to say that the local branch is differently named from the remote 
one.

It is probably worth folding it into the previous patch if you think this 
whole approach is workable.

 git-request-pull.sh | 50 +-
 1 file changed, 29 insertions(+), 21 deletions(-)

diff --git a/git-request-pull.sh b/git-request-pull.sh
index 659a412155d8..c8ab0e912011 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -47,19 +47,23 @@ fi
 
 #
 # $3 must be a symbolic ref, a unique ref, or
-# a SHA object expression
+# a SHA object expression. It can also be of
+# the format 'local-name:remote-name'.
 #
-head=$(git symbolic-ref -q "${3-HEAD}")
-head=${head:-$(git show-ref "${3-HEAD}" | cut -d' ' -f2)}
-head=${head:-$(git rev-parse --quiet --verify "$3")}
+local=${3%:*}
+local=${local:-HEAD}
+remote=${3#*:}
+head=$(git symbolic-ref -q "$local")
+head=${head:-$(git show-ref --heads --tags "$local" | cut -d' ' -f2)}
+head=${head:-$(git rev-parse --quiet --verify "$local")}
 
 # None of the above? Bad.
-test -z "$head" && die "fatal: Not a valid revision: $3"
+test -z "$head" && die "fatal: Not a valid revision: $local"
 
 # This also verifies that the resulting head is unique:
 # "git show-ref" could have shown multiple matching refs..
 headrev=$(git rev-parse --verify --quiet "$head"^0)
-test -z "$headrev" && die "fatal: Ambiguous revision: $3"
+test -z "$headrev" && die "fatal: Ambiguous revision: $local"
 
 # Was it a branch with a description?
 branch_name=${head#refs/heads/}
@@ -69,9 +73,6 @@ then
branch_name=
 fi
 
-prettyhead=${head#refs/}
-prettyhead=${prettyhead#heads/}
-
 merge_base=$(git merge-base $baserev $headrev) ||
 die "fatal: No commits in common between $base and $head"
 
@@ -81,30 +82,37 @@ die "fatal: No commits in common between $base and $head"
 #
 # Otherwise find a random ref that matches $headrev.
 find_matching_ref='
-   my ($exact,$found);
+   my ($head,$headrev) = (@ARGV);
+   my ($found);
+
while () {
+   chomp;
my ($sha1, $ref, $deref) = /^(\S+)\s+([^^]+)(\S*)$/;
-   next unless ($sha1 eq $ARGV[1]);
-   if ($ref eq $ARGV[0]) {
-   $exact = $ref;
+   my ($pattern);
+   next unless ($sha1 eq $headrev);
+
+   $pattern="/$head\$";
+   if ($ref eq $head) {
+   $found = $ref;
+   }
+   if ($ref =~ /$pattern/) {
+   $found = $ref;
}
-   if ($sha1 eq $ARGV[0]) {
+   if ($sha1 eq $head) {
$found = $sha1;
}
}
-   if ($exact) {
-   print "$exact\n";
-   } elsif ($found) {
+   if ($found) {
print "$found\n";
}
 '
 
-ref=$(git ls-remote "$url" | @@PERL@@ -e "$find_matching_ref" "$head" 
"$headrev")
+ref=$(git ls-remote "$url" | @@PERL@@ -e "$find_matching_ref" 
"${remote:-HEAD}" "$headrev")
 
 if test -z "$ref"
 then
-   echo "warn: No match for $prettyhead found at $url" >&2
-   echo "warn: Are you sure you pushed '$prettyhead' there?" >&2
+   echo "warn: No match for commit $headrev found at $url" >&2
+   echo "warn: Are you sure you pushed '${remote:-HEAD}' there?" >&2
status=1
 fi
 
@@ -116,7 +124,7 @@ git show -s --format='The following changes since commit %H:
 
 are available in the git repository at:
 ' $merge_base &&
-echo "  $url $prettyhead" &&
+echo "  $url $remote" &&
 git show -s --format='
 for you to fetch changes up to %H:
 
-- 
1.9.rc0.10.gf0799f9.dirty

--
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] repack: accept larger window-memory and max-pack-size

[Jeff King]

On Wed, Jan 22, 2014 at 11:58:05AM -0800, Junio C Hamano wrote:

> These quantities can be larger than an int.  Use ulong to express
> them like the underlying pack-objects does, and also parse them with
> the human-friendly unit suffixes.

Hrm. I think that is a valid strategy, but...

> - int max_pack_size = 0;
> + unsigned long max_pack_size = 0, window_memory = 0;

Here we must use the correct C type...

> - OPT_INTEGER(0, "window-memory", &window_memory,
> + OPT_HUM_ULONG(0, "window-memory", &window_memory,

And here use the correct parser...

>   if (window_memory)
> - argv_array_pushf(&cmd_args, "--window-memory=%u", 
> window_memory);
> + argv_array_pushf(&cmd_args, "--window-memory=%lu", 
> window_memory);

And here use the correct format string...

All of which must match what pack-objects does, or we risk a further
break (though I do not guess it will change from ulong anytime soon).
The original shell version worked because they were all strings. We do
not care about the numeric value here, and are just forwarding the value
along to pack-objects. Why not just use a string?

The only advantage I can think of is that this gives us slightly earlier
error detection for "git repack --window-memory=bogosity".

But I think there is a subtle problem. Here (and elsewhere) we use the
parsed value of "0" as a sentinel. I think that is OK for
--max-pack-size, where "0" is not a reasonable value. But git-repack(1)
says:

  --window-memory=0 makes memory usage unlimited, which is the default.

What does:

  git config pack.windowMemory 256m
  git repack --window-memory=0

do? It should override the config, but I think it does not with your
patch (nor with the current code). Using a string would fix that (though
you could also fix it by using a different sentinel, like ULONG_MAX).

>   if (max_pack_size)
> - argv_array_pushf(&cmd_args, "--max_pack_size=%u", 
> max_pack_size);
> + argv_array_pushf(&cmd_args, "--max_pack_size=%lu", 
> max_pack_size);

These underscores are interesting:

  $ git pack-objects --max_pack_size=256m
  error: unknown option `max_pack_size=256m'

I get the feeling the test suite does not cover this feature very well.
:)

-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 v2 2/2] repack: accept larger window-memory and max-pack-size

[Jeff King]

On Wed, Jan 22, 2014 at 08:06:42PM -0500, Jeff King wrote:

> But I think there is a subtle problem. Here (and elsewhere) we use the
> parsed value of "0" as a sentinel. I think that is OK for
> --max-pack-size, where "0" is not a reasonable value. But git-repack(1)
> says:
> 
>   --window-memory=0 makes memory usage unlimited, which is the default.
> 
> What does:
> 
>   git config pack.windowMemory 256m
>   git repack --window-memory=0
> 
> do? It should override the config, but I think it does not with your
> patch (nor with the current code). Using a string would fix that (though
> you could also fix it by using a different sentinel, like ULONG_MAX).

Here is a series that does that (and fixes the other issue I found). It
would probably be nice to test these things, but checking that they
actually had an impact is tricky (how do you know that --window-memory
did the right thing?).

  [1/3]: repack: fix typo in max-pack-size option
  [2/3]: repack: make parsed string options const-correct
  [3/3]: repack: propagate pack-objects options as strings

-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

[PATCH 1/3] repack: fix typo in max-pack-size option

[Jeff King]

When we see "--max-pack-size", we accidentally propagated
this to pack-objects as "--max_pack_size", which does not
work at all.

Signed-off-by: Jeff King 
---
 builtin/repack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/repack.c b/builtin/repack.c
index ba66c6e..528725b 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -191,7 +191,7 @@ int cmd_repack(int argc, const char **argv, const char 
*prefix)
if (depth)
argv_array_pushf(&cmd_args, "--depth=%u", depth);
if (max_pack_size)
-   argv_array_pushf(&cmd_args, "--max_pack_size=%u", 
max_pack_size);
+   argv_array_pushf(&cmd_args, "--max-pack-size=%u", 
max_pack_size);
if (no_reuse_delta)
argv_array_pushf(&cmd_args, "--no-reuse-delta");
if (no_reuse_object)
-- 
1.8.5.2.500.g8060133

--
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 2/3] repack: make parsed string options const-correct

[Jeff King]

When we use OPT_STRING to parse an option, we get back a
pointer into the argv array, which should be "const char *".
The compiler doesn't notice because it gets passed through a
"void *" in the option struct.

Signed-off-by: Jeff King 
---
Not a big deal, but just for consistency with the next patch.

 builtin/repack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/repack.c b/builtin/repack.c
index 528725b..7f89c7c 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -129,7 +129,7 @@ int cmd_repack(int argc, const char **argv, const char 
*prefix)
/* variables to be filled by option parsing */
int pack_everything = 0;
int delete_redundant = 0;
-   char *unpack_unreachable = NULL;
+   const char *unpack_unreachable = NULL;
int window = 0, window_memory = 0;
int depth = 0;
int max_pack_size = 0;
-- 
1.8.5.2.500.g8060133

--
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 3/3] repack: propagate pack-objects options as strings

[Jeff King]

In the original shell version of git-repack, any options
destined for pack-objects were left as strings, and passed
as a whole. Since the C rewrite in commit a1bbc6c (repack:
rewrite the shell script in C, 2013-09-15), we now parse
these values to integers internally, then reformat the
integers when passing the option to pack-objects.

This has the advantage that we catch format errors earlier
(i.e., when repack is invoked, rather than when pack-objects
is invoked).

It has three disadvantages, though:

  1. Our internal data types may not be the right size. In
 the case of "--window-memory" and "--max-pack-size",
 these are "unsigned long" in pack-objects, but we can
 only represent a regular "int".

  2. Our parsing routines might not be the same as those of
 pack-objects. For the two options above, pack-objects
 understands "100m" to mean "100 megabytes", but repack
 does not.

  3. We have to keep a sentinel value to know whether it is
 worth passing the option along. In the case of
 "--window-memory", we currently do not pass it if the
 value is "0". But that is a meaningful value to
 pack-objects, where it overrides any configured value.

We can fix all of these by simply passing the strings from
the user along to pack-objects verbatim. This does not
actually fix anything for "--depth" or "--window", but these
are converted, too, for consistency.

Signed-off-by: Jeff King 
---
So we lose the advantage listed above. But I think the simplicity and
future-proofing is worth it (and in this case, we basically don't do
anything _except_ invoke pack-objects, so it is not like we do a bunch
of early work that has to be undone when we find out that the option is
bogus later on).

 builtin/repack.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/builtin/repack.c b/builtin/repack.c
index 7f89c7c..6284846 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -130,9 +130,9 @@ int cmd_repack(int argc, const char **argv, const char 
*prefix)
int pack_everything = 0;
int delete_redundant = 0;
const char *unpack_unreachable = NULL;
-   int window = 0, window_memory = 0;
-   int depth = 0;
-   int max_pack_size = 0;
+   const char *window = NULL, *window_memory = NULL;
+   const char *depth = NULL;
+   const char *max_pack_size = NULL;
int no_reuse_delta = 0, no_reuse_object = 0;
int no_update_server_info = 0;
int quiet = 0;
@@ -157,13 +157,13 @@ int cmd_repack(int argc, const char **argv, const char 
*prefix)
N_("pass --local to git-pack-objects")),
OPT_STRING(0, "unpack-unreachable", &unpack_unreachable, 
N_("approxidate"),
N_("with -A, do not loosen objects older than 
this")),
-   OPT_INTEGER(0, "window", &window,
+   OPT_STRING(0, "window", &window, N_("n"),
N_("size of the window used for delta 
compression")),
-   OPT_INTEGER(0, "window-memory", &window_memory,
+   OPT_STRING(0, "window-memory", &window_memory, N_("bytes"),
N_("same as the above, but limit memory size 
instead of entries count")),
-   OPT_INTEGER(0, "depth", &depth,
+   OPT_STRING(0, "depth", &depth, N_("n"),
N_("limits the maximum delta depth")),
-   OPT_INTEGER(0, "max-pack-size", &max_pack_size,
+   OPT_STRING(0, "max-pack-size", &max_pack_size, N_("bytes"),
N_("maximum size of each packfile")),
OPT_END()
};
@@ -185,13 +185,13 @@ int cmd_repack(int argc, const char **argv, const char 
*prefix)
argv_array_push(&cmd_args, "--all");
argv_array_push(&cmd_args, "--reflog");
if (window)
-   argv_array_pushf(&cmd_args, "--window=%u", window);
+   argv_array_pushf(&cmd_args, "--window=%s", window);
if (window_memory)
-   argv_array_pushf(&cmd_args, "--window-memory=%u", 
window_memory);
+   argv_array_pushf(&cmd_args, "--window-memory=%s", 
window_memory);
if (depth)
-   argv_array_pushf(&cmd_args, "--depth=%u", depth);
+   argv_array_pushf(&cmd_args, "--depth=%s", depth);
if (max_pack_size)
-   argv_array_pushf(&cmd_args, "--max-pack-size=%u", 
max_pack_size);
+   argv_array_pushf(&cmd_args, "--max-pack-size=%s", 
max_pack_size);
if (no_reuse_delta)
argv_array_pushf(&cmd_args, "--no-reuse-delta");
if (no_reuse_object)
-- 
1.8.5.2.500.g8060133
--
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 3/3] repack: propagate pack-objects options as strings

[Jeff King]

On Wed, Jan 22, 2014 at 08:30:13PM -0500, Jeff King wrote:

> - OPT_INTEGER(0, "window", &window,
> + OPT_STRING(0, "window", &window, N_("n"),
>   N_("size of the window used for delta 
> compression")),

By the way, the old code with OPT_INTEGER would always say "n" here, so
there is no change to "git repack -h" output here...

> - OPT_INTEGER(0, "max-pack-size", &max_pack_size,
> + OPT_STRING(0, "max-pack-size", &max_pack_size, N_("bytes"),
>   N_("maximum size of each packfile")),

...but this one will now say:

--max-pack-size 
  maximum size of each packfile

I think that is more descriptive, but pack-objects does just say "n".  I
am OK with it either way.

-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: libz and RHEL 5.9 compile of Git

[Jeff King]

On Wed, Jan 22, 2014 at 01:27:09PM -0800, salmansheikh wrote:

> Got it working but then I had some issues with the perl portions of the
> install and I subsequently thought I could eliminate those portions and
> tried setting export NO_PERL=1 and that installed everything else...and got
> pass this error but when I tried to checkout a git repository as follows, I
> get some remote helper error. Is that related to the perl parts of the git? 
> 
> git clone https://github.com/m-labs/migen.git
> Cloning into 'migen'...
> fatal: Unable to find remote helper for 'https'

Did you build with libcurl support? That's what all of the https code is
built on.

-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 v4 08/23] ewah: compressed bitmap implementation

[Jonathan Nieder]

Hi,

Jeff King wrote:

> EWAH is a word-aligned compressed variant of a bitset (i.e. a data
> structure that acts as a 0-indexed boolean array for many entries).

I suspect that for some callers it's not word-aligned.

Without the following squashed in, commits 212f2ffb and later fail t5310
on some machines[1].

On ARMv5:

expecting success: 
git rev-list --test-bitmap HEAD

*** Error in `/«PKGBUILDDIR»/git': realloc(): invalid pointer: 
0x008728b0 ***
Aborted
not ok 3 - rev-list --test-bitmap verifies bitmaps

On sparc:

expecting success: 
git rev-list --test-bitmap HEAD

Bus error
not ok 3 - rev-list --test-bitmap verifies bitmaps

Hopefully it's possible to get the alignment right in the caller
and tweak the signature to require that instead of using unaligned
reads like this.  There's still something wrong after this patch ---
the new result is a NULL pointer dereference in t5310.7 "enumerate
--objects (full bitmap)".

  (gdb) run
  Starting program: /home/jrnieder/src/git/git rev-list --objects 
--use-bitmap-index HEAD
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/sparc-linux-gnu/libthread_db.so.1".
  537ea4d3eb79c95f602873b1167c480006d2ac2d
[...]
  ec635144f60048986bc560c5576355344005e6e7

  Program received signal SIGSEGV, Segmentation fault.
  0x001321c0 in sha1_to_hex (sha1=0x0) at hex.c:68
  68  unsigned int val = *sha1++;
  (gdb) bt
  #0  0x001321c0 in sha1_to_hex (sha1=0x0) at hex.c:68
  #1  0x000b839c in show_object_fast (sha1=0x0, type=OBJ_TREE, exclude=0, 
name_hash=0, found_pack=0x2b8480, found_offset=4338) at builtin/rev-list.c:270
  #2  0x00158abc in show_objects_for_type (objects=0x2b2498, 
type_filter=0x2b0fb0, object_type=OBJ_TREE, show_reach=0xb834c 
) at pack-bitmap.c:640
  #3  0x001592d0 in traverse_bitmap_commit_list (show_reachable=0xb834c 
) at pack-bitmap.c:818
  #4  0x000b894c in cmd_rev_list (argc=2, argv=0xd688, prefix=0x0) at 
builtin/rev-list.c:369
  #5  0x00014024 in run_builtin (p=0x256e38 , argc=4, 
argv=0xd688) at git.c:314
  #6  0x00014330 in handle_builtin (argc=4, argv=0xd688) at git.c:487
  #7  0x000144a8 in run_argv (argcp=0xd5ec, argv=0xd5a0) at git.c:533
  #8  0x000146fc in main (argc=4, av=0xd684) at git.c:616
  (gdb) frame 2
  #2  0x00158abc in show_objects_for_type (objects=0x2b2498, 
type_filter=0x2b0fb0, object_type=OBJ_TREE, show_reach=0xb834c 
) at pack-bitmap.c:640
  640 show_reach(sha1, object_type, 0, hash, 
bitmap_git.pack, entry->offset);
  (gdb) p entry->nr
  $1 = 4294967295

Line numbers are in the context of 8e6341d9.  Ideas?

[1] ARMv5 and sparc:
https://buildd.debian.org/status/logs.php?pkg=git&suite=experimental

diff --git a/ewah/ewah_io.c b/ewah/ewah_io.c
index aed0da6..696a8ec 100644
--- a/ewah/ewah_io.c
+++ b/ewah/ewah_io.c
@@ -110,25 +110,38 @@ int ewah_serialize(struct ewah_bitmap *self, int fd)
return ewah_serialize_to(self, write_helper, (void *)(intptr_t)fd);
 }
 
+#define get_be32(p) ( \
+   (*((unsigned char *)(p) + 0) << 24) | \
+   (*((unsigned char *)(p) + 1) << 16) | \
+   (*((unsigned char *)(p) + 2) <<  8) | \
+   (*((unsigned char *)(p) + 3) <<  0) )
+
+#define get_be64(p) ( \
+   ((uint64_t) get_be32(p) << 32) | \
+   get_be32((unsigned char *)(p) + 4) )
+
 int ewah_read_mmap(struct ewah_bitmap *self, void *map, size_t len)
 {
-   uint32_t *read32 = map;
-   eword_t *read64;
+   unsigned char *p = map;
size_t i;
 
-   self->bit_size = ntohl(*read32++);
-   self->buffer_size = self->alloc_size = ntohl(*read32++);
+   self->bit_size = get_be32(p);
+   p += 4;
+   self->buffer_size = self->alloc_size = get_be32(p);
+   p += 4;
self->buffer = ewah_realloc(self->buffer,
self->alloc_size * sizeof(eword_t));
 
if (!self->buffer)
return -1;
 
-   for (i = 0, read64 = (void *)read32; i < self->buffer_size; ++i)
-   self->buffer[i] = ntohll(*read64++);
+   for (i = 0; i < self->buffer_size; ++i) {
+   self->buffer[i] = get_be64(p);
+   p += 8;
+   }
 
-   read32 = (void *)read64;
-   self->rlw = self->buffer + ntohl(*read32++);
+   self->rlw = self->buffer + get_be32(p);
+   p += 4;
 
return (3 * 4) + (self->buffer_size * 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: [ANNOUNCE] Git v1.9-rc0

[Jeff King]

On Wed, Jan 22, 2014 at 08:30:30PM +, Ken Moffat wrote:

>  Two questions: Does regenerating (e.g. if the tarball has dropped
> out of the cache) change its sums (md5sum or similar) ?  In (beyond)
> linuxfromscratch we use md5sums to verify that a tarball has not
> changed.

The tarballs we auto-generate from tags are cached, but they can
change if the cached version expires _and_ the archive-generation code
changes.

We use "git archive" to generate the tarballs themselves, and then gzip
the with "gzip -n". So it should be consistent from run to run. However,
very occasionally there are bugfixes in "git archive" which can affect
the output. E.g., commit 22f0dcd (archive-tar: split long paths more
carefully, 2013-01-05) changes the representation of certain long paths,
and generating a tarball with and without it will result in different
checksums (for some repos).

So if you are planning on baking md5sums into a package-build system, it
is much better to point at "official" releases which are rolled once by
the project maintainer, rather than the automatic tag page.

Junio, since you prepare such tarballs[1] anyway for kernel.org, it
might be worth uploading them to the "Releases" page of git/git.  I
imagine there is a programmatic way to do so via GitHub's API, but I
don't know offhand. I can look into it if you are interested.

-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 2/3] setup_pager: set MORE=R

[Jeff King]

On Tue, Jan 21, 2014 at 12:42:58AM -0800, Kyle J. McKay wrote:

> This attempts to show colors but doesn't work properly:
> 
>   LESS=-+R git -c color.ui=auto -c color.pager=true log --oneline --graph
> 
> but this does
> 
>   LESS=-R git -c color.ui=auto -c color.pager=true log --oneline --graph
> 
> so yeah, just checking for 'R' in $LESS is only approximate.  :)
> Also -r is good enough to show colors too...

Ugh, yeah. I think LESS=+R would also break. Doing it right would
involve parsing less's option format, including "-", "+", and "-+". It's
not _that_ much code, but it feels awfully wrong to be so intimate with
a subprogram that we do not control.

-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

[PATCH v3] git-svn: memoize _rev_list and rebuild

[manjian2006]

From: lin zuojian 

According to profile data, _rev_list and rebuild consume a large
portion of time.  Memoize the results of _rev_list and memoize
rebuild internals to avoid subprocess invocation.

When importing 15152 revisions on a LAN, time improved from 10
hours to 3-4 hours.

Signed-off-by: lin zuojian 
---
 perl/Git/SVN.pm | 41 ++---
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 5273ee8..6e804a2 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1599,6 +1599,7 @@ sub tie_for_persistent_memoization {
my %lookup_svn_merge_cache;
my %check_cherry_pick_cache;
my %has_no_changes_cache;
+   my %_rev_list_cache;
 
tie_for_persistent_memoization(\%lookup_svn_merge_cache,
"$cache_path/lookup_svn_merge");
@@ -1620,6 +1621,14 @@ sub tie_for_persistent_memoization {
SCALAR_CACHE => ['HASH' => \%has_no_changes_cache],
LIST_CACHE => 'FAULT',
;
+
+   tie_for_persistent_memoization(\%_rev_list_cache,
+   "$cache_path/_rev_list");
+   memoize '_rev_list',
+   SCALAR_CACHE => 'FAULT',
+   LIST_CACHE => ['HASH' => \%_rev_list_cache],
+   ;
+
}
 
sub unmemoize_svn_mergeinfo_functions {
@@ -1629,6 +1638,7 @@ sub tie_for_persistent_memoization {
Memoize::unmemoize 'lookup_svn_merge';
Memoize::unmemoize 'check_cherry_pick';
Memoize::unmemoize 'has_no_changes';
+   Memoize::unmemoize '_rev_list';
}
 
sub clear_memoized_mergeinfo_caches {
@@ -1959,11 +1969,25 @@ sub rebuild_from_rev_db {
unlink $path or croak "unlink: $!";
 }
 
+#define a global associate map to record rebuild status
+my %rebuild_status;
+#define a global associate map to record rebuild verify status
+my %rebuild_verify_status;
+
 sub rebuild {
my ($self) = @_;
my $map_path = $self->map_path;
my $partial = (-e $map_path && ! -z $map_path);
-   return unless ::verify_ref($self->refname.'^0');
+   my $verify_key = $self->refname.'^0';
+   if (!$rebuild_verify_status{$verify_key}) {
+   my $verify_result = ::verify_ref($verify_key);
+   if ($verify_result) {
+   $rebuild_verify_status{$verify_key} = 1;
+   }
+   }
+   if (!$rebuild_verify_status{$verify_key}) {
+   return;
+   }
if (!$partial && ($self->use_svm_props || $self->no_metadata)) {
my $rev_db = $self->rev_db_path;
$self->rebuild_from_rev_db($rev_db);
@@ -1977,10 +2001,21 @@ sub rebuild {
print "Rebuilding $map_path ...\n" if (!$partial);
my ($base_rev, $head) = ($partial ? $self->rev_map_max_norebuild(1) :
(undef, undef));
+   my $key_value = ($head ? "$head.." : "") . $self->refname;
+   if (exists $rebuild_status{$key_value}) {
+   print "Done rebuilding $map_path\n" if (!$partial || !$head);
+   my $rev_db_path = $self->rev_db_path;
+   if (-f $self->rev_db_path) {
+   unlink $self->rev_db_path or croak "unlink: $!";
+   }
+   $self->unlink_rev_db_symlink;
+   return;
+   }
my ($log, $ctx) =
-   command_output_pipe(qw/rev-list --pretty=raw --reverse/,
-   ($head ? "$head.." : "") . $self->refname,
+   command_output_pipe(qw/rev-list --pretty=raw --reverse/,
+   $key_value,
'--');
+   $rebuild_status{$key_value} = 1;
my $metadata_url = $self->metadata_url;
remove_username($metadata_url);
my $svn_uuid = $self->rewrite_uuid || $self->ra_uuid;
-- 
1.8.3.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

WIth git-next, writing bitmaps fails when keep files are present

[Siddharth Agarwal]

Running git-next, writing bitmap indexes fails if a keep file is present 
from an earlier pack.


With git at b139ac2, the following commands demonstrate the problem:

git init test
cd test
touch a
git add a
git commit -m "a"

git repack -ad  # generate a pack file
for f in .git/objects/pack/*.pack; touch ${f/%pack/keep}  # mark it as 
to keep


touch b
git add b
git commit -m "b"
git repack -adb

This fails at the bitmap writing stage with something like:

Counting objects: 2, done.
Delta compression using up to 24 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), done.
fatal: Failed to write bitmap index. Packfile doesn't have full closure 
(object 7388a015938147155b600eaacc59af6e78c75e5a is missing)


In our case we have .keep files lying around from ages ago (possibly due 
to kill -9s run on the server). It also means that running repack -a 
with bitmap writing enabled on a repo becomes problematic if a fetch is 
run concurrently.


Even if we practice good .keep hygiene, this seems like a bug in git 
that should be fixed.

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

bug with git-diff --quiet

[IWAMOTO Toshihiro]

I found "git-diff --quiet" returns a zero exit status even if there's
a change.  The following sequence reproduces the bug:

  $ mkdir foo
  $ cd foo
  $ git init
  $ echo a > a.txt
  $ echo b >b.txt
  $ git add ?.txt
  $ git commit
  $ echo b >> b.txt
  $ touch a.txt
  $ git diff --quiet; echo $?
  
Interestingly, if you issue "git-diff --quiet" again, it returns the
expected exit status 1.

The problem is in the optimization code in run_diff_files().  The
function finds a.txt has different stat(2) data from .git/index and
calls diff_change(), which sets DIFF_OPT_HAS_CHANGES.  As the flag
makes diff_can_quit_early() return 1, run_diff_files()'s loop finishes
without calling diff_change() for b.txt.

Then, diffcore_std() examines diff_queued_diff and clears
DIFF_OPT_HAS_CHANGES, because a.txt is unchanged.
This is how a change in b.txt is ignored by git-diff --quiet.

Here's a obvious fix for this bug, but I think you can find a better
fix. Thanks in advance.


diff --git a/diff-lib.c b/diff-lib.c
index 346cac6..0b8c58d 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -105,9 +105,6 @@ int run_diff_files(struct rev_info *revs, unsigned int 
option)
int changed;
unsigned dirty_submodule = 0;
 
-   if (diff_can_quit_early(&revs->diffopt))
-   break;
-
if (!ce_path_match(ce, &revs->prune_data))
continue;
 
--
IWAMOTO Toshihiro
--
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 v3] git-svn: memoize _rev_list and rebuild

[Eric Wong]

manjian2...@gmail.com wrote:
> According to profile data, _rev_list and rebuild consume a large
> portion of time.  Memoize the results of _rev_list and memoize
> rebuild internals to avoid subprocess invocation.
> 
> When importing 15152 revisions on a LAN, time improved from 10
> hours to 3-4 hours.
> 
> Signed-off-by: lin zuojian 

Thanks!
Signed-off-by: Eric Wong 
Pushed for Junio.

The following changes since commit d9bb4be53bc5185244b4be9860562a012803bacb:

  Merge tag 'gitgui-0.19.0' of http://repo.or.cz/r/git-gui (2014-01-21 13:16:17 
-0800)

are available in the git repository at:


  git://git.bogomips.org/git-svn.git master

for you to fetch changes up to ab0bcec9873f1fcef6c4b8825cc9e762c636ca9e:

  git-svn: memoize _rev_list and rebuild (2014-01-23 02:54:26 +)


lin zuojian (1):
  git-svn: memoize _rev_list and rebuild

 perl/Git/SVN.pm | 41 ++---
 1 file changed, 38 insertions(+), 3 deletions(-)
--
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 1/4] subtree: support split --rejoin --squash

[Matthew Ogilvie]

On Wed, Jan 22, 2014 at 03:58:28PM +0100, Pierre Penninckx wrote:
> 2013/12/7 Matthew Ogilvie 
> > Subject: [PATCH 1/4] subtree: support split --rejoin --squash
> >
> > Allow using --squash with "git subtree split --rejoin".  It
> > will still split off (and save to --branch) the complete
> > subtree history, but the merge done for the "--rejoin" will
> > be merging a squashed representation of the new subtree
> > commits, instead of the commits themselves (similar to
> > how "git subtree merge --squash" works).
> >
> > Signed-off-by: Matthew Ogilvie 
> > ---
> >
> > I can think of a couple of possible objections to this patch.
> > Are these (or any others) worth fixing?
> >
> > 1. Perhaps someone want the saved subtree (--branch) to have
> >a squashed representation as well, as an option?  Maybe we
> >need two different --squash options?  Something
> >like "--rejoin-squash"?
> > 2. It could definitely use some automated tests.  In fact,
> >pre-existing --squash functionality is hardly tested at
> >all, either.
> >   See patch 4 comments for a script I use to help with
> >mostly-manual testing.
>
> Sorry to bother you with this again, but I was wondering if those patches
> would be integrated into git anytime soon.
> And if not, if there is something I can do to help.
> 
> I found them by the way, thanks a lot!
> 
> Pierre

I'm not sure when or if the patches will make it in.  Junio's
weekly "What's cooking..." email has asked for "Comments?" about
them for the past several weeks, but I have yet to see
anyone actually comment about them.

Searching throught the last couple of years of mailing list
archives for "subtree" reveals a general lack of a active
maintainer(s) to help review and improve patches for "git
subtree".  Given the general lack of help and feedback, it is
understandable that Junio has largely limited inclusion of
subtree patches to trivially obvious bug fixes.

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

Nike Footwear Fulfill Distinct Desires involving Consumers

[laura3]

 

For Nike, that likes a worldwide celebrity. These days, you'll find
innumerable forms of goods manufactured by Nike Provider, on the other hand,
in terms of the most popular kinds, that really should become  nike free 
damen    boots and shoes,
becoming prominent inside completely earth. To begin with, Nike ended up
referred to as Nike Atmosphere Jordan boots and shoes. These types of boots
and shoes will be rich in appeal and boldness and maybe they are really
wonderful people.

Amongst many of the properties with Nike, the most known some may be their
particular matchless swiftness. For this reason, for most athletes
throughout anyone who cares to, Nike are usually unquestionably suitable and
also needed objects. For Atmosphere Jordan shoes, there're which will posses
an significant feature, we. electronic, there're amazing. The design with 
nike schuhe damen    surroundings are
and so amazing as well as stunning which they usually are beyond your
visualization.

Nike air max 90 sale   
sports may be consumed to get an example because a kind of really
sophisticated in addition to impressive sneakers favorite by sports devotees
within the full entire world these days. For a matter connected with truth,
for several well-known football celebrities, express, Rooney, Ronaldo, Figo,
Henry, and others, football are generally the widespread alternative that
can be played video games.

About golf ball shoes, there're really beautiful and also amazing types, and
with these people on paws, hockey gamers tend to turn into much more
sensitive on the judge. Amid a variety of bouncing boots and shoes, they can
be unquestionably counted seeing that fantastic types. In addition  nike
schuhe herren    Atmosphere Jordan
shoes, there's also some other forms of the most effective sneakers,
express, Weather Sporting shoes, the prominent type treasured by
international players.



--
View this message in context: 
http://git.661346.n2.nabble.com/Nike-Footwear-Fulfill-Distinct-Desires-involving-Consumers-tp7602441.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] Makefile: Fix compilation of Windows resource file

[Johannes Sixt]

From: Johannes Sixt 

If the git version number consists of less than three period
separated numbers, then the Windows resource file compilation
issues a syntax error:

  $ touch git.rc
  $ make V=1 git.res
  GIT_VERSION = 1.9.rc0
  windres -O coff \
-DMAJOR=1 -DMINOR=9 -DPATCH=rc0 \
-DGIT_VERSION="\\\"1.9.rc0\\\"" git.rc -o git.res
  C:\msysgit\msysgit\mingw\bin\windres.exe: git.rc:2: syntax error
  make: *** [git.res] Error 1
  $

Note that -DPATCH=rc0.

The values passed via -DMAJOR=, -DMINOR=, and -DPATCH= are used in
FILEVERSION and PRODUCTVERSION statements, which expect up to four numeric
values. These version numbers are intended for machine consumption. They
are typically inspected by installers to decide whether a file to be
installed is newer than one that exists on the system, but are not used
for much else.

We can be pretty certain that there are no tools that look at these
version numbers, not even the installer of Git for Windows does.
Therefore, to fix the syntax error, fill in only the first two numbers,
which we are guaranteed to find in Git version numbers.

Signed-off-by: Johannes Sixt 
---
 That "not even the installer of Git for Windows uses" the FILEVERSION
 numbers is a bold statement of mine (I did not check). If I am wrong,
 this approach for a fix is not viable, and a better fix would be
 needed. Otherwise, an Acked-By would be appreciated so that we can
 have this fix in upstream ASAP.

 Makefile | 2 +-
 git.rc   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index b4af1e2..99b2b89 100644
--- a/Makefile
+++ b/Makefile
@@ -1773,7 +1773,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES
 
 git.res: git.rc GIT-VERSION-FILE
$(QUIET_RC)$(RC) \
- $(join -DMAJOR= -DMINOR= -DPATCH=, $(wordlist 1,3,$(subst -, ,$(subst 
., ,$(GIT_VERSION) \
+ $(join -DMAJOR= -DMINOR=, $(wordlist 1,2,$(subst -, ,$(subst ., 
,$(GIT_VERSION) \
  -DGIT_VERSION="\\\"$(GIT_VERSION)\\\"" $< -o $@
 
 ifndef NO_PERL
diff --git a/git.rc b/git.rc
index bce6db9..33aafb7 100644
--- a/git.rc
+++ b/git.rc
@@ -1,6 +1,6 @@
 1 VERSIONINFO
-FILEVERSION MAJOR,MINOR,PATCH,0
-PRODUCTVERSION  MAJOR,MINOR,PATCH,0
+FILEVERSION MAJOR,MINOR,0,0
+PRODUCTVERSION  MAJOR,MINOR,0,0
 BEGIN
   BLOCK "StringFileInfo"
   BEGIN
-- 
1.9.rc0.1179.g5088b55
--
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