[PATCH v2] improve git svn performance
From: manjian2006 manjian2...@gmail.com
* perl/Git/SVN.pm
Modified according to Eric Wong normalper...@yhbt.net
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 manjian2...@gmail.com
---
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
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org 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.
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
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 astrilhay...@gmail.com 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
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
Add cross-references between the manpages for git-for-each-ref(1) and git-show-ref(1). Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- 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 git@vger.kernel.org. +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
On Wed, Jan 22, 2014 at 6:22 PM, Michael Haggerty mhag...@alum.mit.edu 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
On Wed, Jan 22, 2014 at 12:39 PM, Duy Nguyen pclo...@gmail.com wrote: On Wed, Jan 22, 2014 at 6:22 PM, Michael Haggerty mhag...@alum.mit.edu 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, jo...@herland.net 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
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 ...
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
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 ...
On Jan 22, 2014, at 9:20 AM, John McIntyre joh98@gmail.com 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 ...
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 and...@kellerfarm.com: On Jan 22, 2014, at 9:20 AM, John McIntyre joh98@gmail.com 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
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 freeman...@gmail.com 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 jon.seym...@gmail.com 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 freeman...@gmail.com 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 sand...@crustytoothpaste.net 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
Re: [ANNOUNCE] Git v1.9-rc0
Javier Domingo Cansino javier...@gmail.com 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
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
Michael Haggerty mhag...@alum.mit.edu 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
Michael Haggerty mhag...@alum.mit.edu writes: Add cross-references between the manpages for git-for-each-ref(1) and git-show-ref(1). Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- 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
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
Stefan Näwe stefan.na...@atlas-elektronik.com 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
Johannes Sixt j.s...@viscovery.net writes: [Cc Pat, who added git.rc] Am 1/22/2014 0:48, schrieb Junio C Hamano: Ramsay Jones ram...@ramsay1.demon.co.uk 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
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
Am 1/22/2014 17:12, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net writes:
[Cc Pat, who added git.rc]
Am 1/22/2014 0:48, schrieb Junio C Hamano:
Ramsay Jones ram...@ramsay1.demon.co.uk 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
On Wed, Jan 22, 2014 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Näwe stefan.na...@atlas-elektronik.com 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
Johannes Sixt j.s...@viscovery.net 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
Vicent Martí tan...@gmail.com 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
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
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
On Wed, Jan 22, 2014 at 3:22 AM, Michael Haggerty mhag...@alum.mit.edu 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
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 gits...@pobox.com --- 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
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 gits...@pobox.com
---
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_OPT_LITERAL_ARGHELP = 64,
+ PARSE_OPT_HUMAN_NUMBER = 128,
[PATCH v2 0/2] Fix repack --window-memory=4g regression in 1.8.4
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
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 gits...@pobox.com writes: Johannes Sixt j.s...@viscovery.net 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
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.
Paul Mackerras pau...@samba.org 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
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 brad.k...@kitware.com --- 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 + ) 2actual-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 + ) 2actual-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
manjian2...@gmail.com wrote:
* perl/Git/SVN.pm
Modified according to Eric Wong normalper...@yhbt.net
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 manjian2...@gmail.com
Real name is preferred by this project, I think.
A proper patch would start something like this:
---8
From: Your Name manjian2...@gmail.com
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 manjian2...@gmail.com
-- 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/
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
On Wed, Jan 22, 2014 at 10:10:18AM -0800, Junio C Hamano wrote: Vicent Martí tan...@gmail.com 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
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
Ken Moffat zarniwh...@ntlworld.com 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
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
From: Linus Torvalds torva...@linux-foundation.org
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 torva...@linux-foundation.org
---
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 remote
-# and
RE: Problem importing from SVN repository with branches/tags at multiple levels using git-svn
-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
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
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
Linus Torvalds torva...@linux-foundation.org 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
On Wed, Jan 22, 2014 at 1:46 PM, Junio C Hamano gits...@pobox.com 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
On Wed, Jan 22, 2014 at 2:03 PM, Linus Torvalds torva...@linux-foundation.org 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
Linus Torvalds torva...@linux-foundation.org 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
On Wed, Jan 22, 2014 at 2:14 PM, Junio C Hamano gits...@pobox.com 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 gits...@pobox.com 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
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
gits...@pobox.com wrote on Tue, 21 Jan 2014 16:03 -0800: Pete Wyckoff p...@padd.com 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
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 p...@padd.com --- 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 04/11] git p4 test: explicitly check p4 wildcard delete
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 p...@padd.com --- 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
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 dam...@iwi.me
Signed-off-by: Pete Wyckoff p...@padd.com
---
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
More majordomo info at
[PATCHv2 05/11] git p4 test: is_cli_file_writeable succeeds
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 p...@padd.com --- 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
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 p...@padd.com
---
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 alice@localhost -m a change by
alice file1
- git commit --author Bob bob@localhost -m a change by bob
file2
+ git commit --author Alice al...@example.com -m a change by
alice file1
+ git commit --author Bob b...@example.com -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 alice@localhost -m perms: a
change by alice file1
+ git commit --author Alice al...@example.com -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 bob@localhost -m preserve: a
change by bob file1
+ git commit --author Bob b...@example.com -m preserve: a
change by bob file1
echo username-unknown: a change by charlie file1
- git commit --author Charlie charlie@localhost -m preserve:
a change by charlie file1
+ git commit --author Charlie char...@example.com -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
[PATCHv2 08/11] git p4: handle files with wildcards when doing RCS scrubbing
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 p...@padd.com --- 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/ scrub@wild 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
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 p...@padd.com
---
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
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 p...@padd.com
---
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 -m mv file1 to file2
+ git config git-p4.skipSubmitEdit true
+ git config git-p4.detectRenames true
+ git p4 submit --verbose
+ )
+'
+
+test_expect_success 'kill p4d' '
+
[PATCHv2 09/11] git p4: fix an error message when p4 where fails
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 p...@padd.com --- 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
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 p...@padd.com --- 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 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
On Wed, Jan 22, 2014 at 01:04:02PM -0800, Junio C Hamano wrote: Ken Moffat zarniwh...@ntlworld.com 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)
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 'next' on
Re: problematic git log submodule-dir/
On Thu, Jan 23, 2014 at 3:35 AM, Jens Lehmann jens.lehm...@web.de 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
From: Linus Torvalds torva...@linux-foundation.org
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 torva...@linux-foundation.org
---
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 (STDIN) {
+ 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
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
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
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 p...@peff.net --- 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
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 p...@peff.net --- 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
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 p...@peff.net --- 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
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 bytes 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
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
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
show_object_fast) at pack-bitmap.c:640
#3 0x001592d0 in traverse_bitmap_commit_list (show_reachable=0xb834c
show_object_fast) 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 commands+1020, 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
show_object_fast) 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=gitsuite=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
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
[PATCH v3] git-svn: memoize _rev_list and rebuild
From: lin zuojian manjian2...@gmail.com
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 manjian2...@gmail.com
---
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
bug with git-diff --quiet
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
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 manjian2...@gmail.com Thanks! Signed-off-by: Eric Wong normalper...@yhbt.net 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
On Wed, Jan 22, 2014 at 03:58:28PM +0100, Pierre Penninckx wrote: 2013/12/7 Matthew Ogilvie mmogilvi_...@miniinfo.net 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 mmogilvi_...@miniinfo.net --- 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
http://git.661346.n2.nabble.com/file/n7602441/nike.jpg 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 http://www.nikeschuhe-onlinede.com/nike-free 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 http://www.nikeschuhe-onlinede.com/ surroundings are and so amazing as well as stunning which they usually are beyond your visualization. Nike air max 90 sale http://www.nikeschuhe-onlinede.com/nike-air-max 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 http://www.nikeschuhe-onlinede.com/ 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
From: Johannes Sixt j...@kdbg.org 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 j...@kdbg.org --- 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
