* Re: Git User's Survey 2011 very short summary
From: Andrew Ardill @ 2011-10-10 23:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201110101721.51830.jnareb@gmail.com>
Thanks for your work organising this, as always it is very interesting to read.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCHv5/RFC 1/6] Documentation: Preparation for gitweb manpages
From: Junio C Hamano @ 2011-10-10 23:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Drew Northup, Jonathan Nieder
In-Reply-To: <201110102352.25456.jnareb@gmail.com>
I probably do not have time to look into this, but just FYI my trial merge
to 'pu' of this topic is failing like this:
asciidoc: ERROR: gitweb.conf.txt: line 484: illegal style name: Default: ()
asciidoc: ERROR: gitweb.conf.txt: line 494: illegal style name: Default: 300
^ permalink raw reply
* [PATCH v2] git-svn: Allow certain refs to be ignored
From: Michael Olson @ 2011-10-10 23:27 UTC (permalink / raw)
To: Git Mailing List
Implement a new --ignore-refs option which specifies a regex of refs
to ignore while importing svn history.
This is a useful supplement to the --ignore-paths option, as that
option only operates on the contents of branches and tags, not the
branches and tags themselves.
Signed-off-by: Michael Olson <mwolson@gnu.org>
---
Rebased against git master.
git-svn.perl | 38 +++++++++++++++++++++++++++++++++-----
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 351e743..fed1734 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -94,7 +94,8 @@ $_q ||= 0;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
'no-auth-cache' => \$Git::SVN::Prompt::_no_auth_cache,
- 'ignore-paths=s' => \$SVN::Git::Fetcher::_ignore_regex );
+ 'ignore-paths=s' => \$SVN::Git::Fetcher::_ignore_regex,
+ 'ignore-refs=s' => \$Git::SVN::Ra::_ignore_refs_regex );
my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'authors-file|A=s' => \$_authors,
'authors-prog=s' => \$_authors_prog,
@@ -388,9 +389,12 @@ sub do_git_init_db {
command_noisy('config', "$pfx.$i", $icv{$i});
$set = $i;
}
- my $ignore_regex = \$SVN::Git::Fetcher::_ignore_regex;
- command_noisy('config', "$pfx.ignore-paths", $$ignore_regex)
- if defined $$ignore_regex;
+ my $ignore_paths_regex = \$SVN::Git::Fetcher::_ignore_regex;
+ command_noisy('config', "$pfx.ignore-paths", $$ignore_paths_regex)
+ if defined $$ignore_paths_regex;
+ my $ignore_refs_regex = \$Git::SVN::Ra::_ignore_refs_regex;
+ command_noisy('config', "$pfx.ignore-refs", $$ignore_refs_regex)
+ if defined $$ignore_refs_regex;
if (defined $SVN::Git::Fetcher::_preserve_empty_dirs) {
my $fname = \$SVN::Git::Fetcher::_placeholder_filename;
@@ -2119,6 +2123,8 @@ sub read_all_remotes {
$r->{$1}->{url} = $2;
} elsif (m!^(.+)\.pushurl=\s*(.*)\s*$!) {
$r->{$1}->{pushurl} = $2;
+ } elsif (m!^(.+)\.ignore-refs=\s*(.*)\s*$!) {
+ $r->{$1}->{ignore_refs_regex} = $2;
} elsif (m!^(.+)\.(branches|tags)=$svn_refspec$!) {
my ($remote, $t, $local_ref, $remote_ref) =
($1, $2, $3, $4);
@@ -2155,6 +2161,16 @@ sub read_all_remotes {
}
} keys %$r;
+ foreach my $remote (keys %$r) {
+ foreach ( grep { defined $_ }
+ map { $r->{$remote}->{$_} } qw(branches tags) ) {
+ foreach my $rs ( @$_ ) {
+ $rs->{ignore_refs_regex} =
+ $r->{$remote}->{ignore_refs_regex};
+ }
+ }
+ }
+
$r;
}
@@ -5310,7 +5326,7 @@ sub apply_diff {
}
package Git::SVN::Ra;
-use vars qw/@ISA $config_dir $_log_window_size/;
+use vars qw/@ISA $config_dir $_ignore_refs_regex $_log_window_size/;
use strict;
use warnings;
my ($ra_invalid, $can_do_switch, %ignored_err, $RA);
@@ -5768,6 +5784,17 @@ sub get_dir_globbed {
@finalents;
}
+# return value: 0 -- don't ignore, 1 -- ignore
+sub is_ref_ignored {
+ my ($g, $p) = @_;
+ my $refname = $g->{ref}->full_path($p);
+ return 1 if defined($g->{ignore_refs_regex}) &&
+ $refname =~ m!$g->{ignore_refs_regex}!;
+ return 0 unless defined($_ignore_refs_regex);
+ return 1 if $refname =~ m!$_ignore_refs_regex!o;
+ return 0;
+}
+
sub match_globs {
my ($self, $exists, $paths, $globs, $r) = @_;
@@ -5804,6 +5831,7 @@ sub match_globs {
next unless /$g->{path}->{regex}/;
my $p = $1;
my $pathname = $g->{path}->full_path($p);
+ next if is_ref_ignored($g, $p);
next if $exists->{$pathname};
next if ($self->check_path($pathname, $r) !=
$SVN::Node::dir);
--
1.7.4.1
^ permalink raw reply related
* Garbage collection creates many unpacked objects.
From: Martin Fick @ 2011-10-10 23:30 UTC (permalink / raw)
To: git
If I clone linus' kernel, delete all the tags, and then run
git gc, it ends up expanding into about 5K of unpacked
objects. The .git size goes from 473M to 511M. This seems
a bit strange no? Shouldn't gcing yield a smaller repo an
fewer unpacked refs?
If I do this on our internal kernel repo (which has 2Ktags),
it gets much more pathological, it expands to about 1M
objects and grows to about 7G!!!
This seems to happen with all versions which I tested,
1.6.0, 1.7.6 and 1.7.7
Any thoughts?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Sitaram Chamarty @ 2011-10-10 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Phil Hord, Sitaram Chamarty, git
In-Reply-To: <7v8voslg4l.fsf@alter.siamese.dyndns.org>
On Tue, Oct 11, 2011 at 2:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I also wondered if this is easier to read:
>
> pipe | stdin_contains m2 &&
> ! pipe | stdin_contains master
> but I do not think it is (we cannot say "pipe | ! stdin_contains master").
Agreed on both counts.
"pipe | ( ! grep master )" does work, but I suspect that is an
inconsistency in the shell so I didn't want to use it. IIRC the "(
list )" constrict is not supposed to make *that* much difference.
Have to check when I have time.
> In any case, here is what I ended up queuing. Thanks.
> +stdin_doesnot_contain()
> +{
> + ! stdin_contains "$1"
> }
(facepalm) Why didn't I think of that!
Thanks :-)
^ permalink raw reply
* Re: Garbage collection creates many unpacked objects.
From: Shawn Pearce @ 2011-10-10 23:49 UTC (permalink / raw)
To: Martin Fick; +Cc: git
In-Reply-To: <201110101730.43302.mfick@codeaurora.org>
On Mon, Oct 10, 2011 at 16:30, Martin Fick <mfick@codeaurora.org> wrote:
> If I clone linus' kernel, delete all the tags, and then run
> git gc, it ends up expanding into about 5K of unpacked
> objects. The .git size goes from 473M to 511M. This seems
> a bit strange no? Shouldn't gcing yield a smaller repo an
> fewer unpacked refs?
>
> If I do this on our internal kernel repo (which has 2Ktags),
> it gets much more pathological, it expands to about 1M
> objects and grows to about 7G!!!
This is caused by unreachable objects being evicted from packs and
stored as loose objects for up to 2 weeks, until the next `git prune`
run. I think you can avoid this by using `git repack -a -d` instead of
`git gc`, but at the risk that a concurrent modification of the
repository may result in corruption due to a race condition between
the object being needed, and the object being deleted.
^ permalink raw reply
* Re: [PATCH 2/3] Fix some "variable might be used uninitialized" warnings
From: Junio C Hamano @ 2011-10-10 23:59 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4E90751C.4030409@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>> [I don't think traverse_trees() would ever be called with n == 0 anyway; the call
>> site in builtin/merge-tree.c is called with the constant 3, and the call-chains(s)
>> which start from unpack_trees() are protected by "if (len)", where 'len' is unsigned.]
>
> When patches don't even make it to pu I just assume you hate them so much that
> there is not much chance of them being applied and simply forget about them.
> In this case, since compiler warnings are a bugbear of mine, I'm hoping that
> you just forgot about this one ... :-D [if not, sorry for the noise].
Thanks for a reminder.
The reason a patch may not hit 'pu', unless I or other people whose
judgement I trust explicity say "the approach taken by the patch is
utterly wrong" is either because (1) the discussion for or against the
topic is still going strong and there is little chance of it getting
forgotten by everybody, (2) I do not see much discussion for or against
the topic, and I am indifferent, or (3) the patch was just lost in the
noise.
So a good default strategy for a series that do not hit 'pu' is to
re-post. Such a perseverance was what took format-patch to hit Linus's
tree in June-July 2005 timeframe---we wouldn't have the command today, had
I given up back then ;-).
^ permalink raw reply
* Re: [PATCH v3 5/5] attr.c: respect core.ignorecase when matching attribute patterns
From: Junio C Hamano @ 2011-10-11 0:00 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Brandon Casey, git, peff, j.sixt, Brandon Casey
In-Reply-To: <4E91BAC8.9060606@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 10/06/2011 08:22 PM, Brandon Casey wrote:
>> The last set of tests is performed only on a case-insensitive filesystem.
>> Those tests make sure that git handles the case where the .gitignore file
>> resides in a subdirectory and the user supplies a path that does not match
>> the case in the filesystem. In that case^H^H^H^Hsituation, part of the
>> path supplied by the user is effectively interpreted case-insensitively,
>> and part of it is dependent on the setting of core.ignorecase. git should
>> only match the portion of the path below the directory holding the
>> .gitignore file according to the setting of core.ignorecase.
>
> ... It is hard to imagine that
> anybody *wants* part of a single filename to be matched
> case-insensitively and another part to be matched case-sensitively.
That is not necessarily coming from the user's wish. When a command that
takes a pathspec from the user is run from a subdirectory, almost always
the output from $(git rev-parse --show-prefix) is prefixed to them. This
value is read from the filesystem, and unless on a system whose readdir()
may lie to us, we do not _have_ to ignore the case of this part of the
substring of a resulting pathspec element to get a successful match, even
though we _do_ want to match the user-supplied part case insensitively
if/when the user says he wants us to with core.ignorecase.
Having said that, it may not hurt in practice if we matched the prefix
part case insensitvely, because prefix=foobar/ obtained on a filesystem
where core.ignorecase is true would mean there won't be FooBar/ and other
case-permuted names on the filesystem at the same time.
But of course I may be missing something...
^ permalink raw reply
* Re: [PATCH v2 1/7] invalidate_ref_cache(): rename function from invalidate_cached_refs()
From: Junio C Hamano @ 2011-10-11 0:00 UTC (permalink / raw)
To: Michael Haggerty
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland
In-Reply-To: <1318235064-25915-2-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> It is the cache that is being invalidated, not the references.
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
Although I think one can say "ref cache is the container for cached refs"
and invalidating the "ref cache" as the container and invalidating the
"cached refs" as a collection mean essentially the same thing, probably
the new name makes more sense.
> refs.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 2cb93e2..56e4254 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -223,7 +223,7 @@ static struct cached_refs *get_cached_refs(const char *submodule)
> return refs;
> }
>
> -static void invalidate_cached_refs(void)
> +static void invalidate_ref_cache(void)
> {
> struct cached_refs *refs = cached_refs;
> while (refs) {
> @@ -1212,7 +1212,7 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
> ret |= repack_without_ref(refname);
>
> unlink_or_warn(git_path("logs/%s", lock->ref_name));
> - invalidate_cached_refs();
> + invalidate_ref_cache();
> unlock_ref(lock);
> return ret;
> }
> @@ -1511,7 +1511,7 @@ int write_ref_sha1(struct ref_lock *lock,
> unlock_ref(lock);
> return -1;
> }
> - invalidate_cached_refs();
> + invalidate_ref_cache();
> if (log_ref_write(lock->ref_name, lock->old_sha1, sha1, logmsg) < 0 ||
> (strcmp(lock->ref_name, lock->orig_ref_name) &&
> log_ref_write(lock->orig_ref_name, lock->old_sha1, sha1, logmsg) < 0)) {
^ permalink raw reply
* Re: [PATCH da/difftool-mergtool-refactor] Makefile: fix permissions of mergetools/ checked out with permissive umask
From: Junio C Hamano @ 2011-10-11 0:00 UTC (permalink / raw)
To: David Aguilar
Cc: Jonathan Nieder, git@vger.kernel.org, Tanguy Ortolo,
Charles Bailey, SebastianSchuberth
In-Reply-To: <1C9F1683-4C6E-4D49-86D3-3A47B2843F23@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> thanks. I agree that the tar is overkill. I think I copied that snippet
> from templates/makefile. does that have the same bug?
Likely, as I recall that I wrote the installation of templates in an
expecially sloppy way, thinking somebody would fix it in short order
anyway. Instead the sloppiness seems to have been copied and pasted to
make things worse...
Thanks for fixing the mess---all's well that ends well.
^ permalink raw reply
* Re: [PATCH v3] Teach merge the '[-e|--edit]' option
From: Junio C Hamano @ 2011-10-11 0:00 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Todd A. Jacobs
In-Reply-To: <CAG+J_Dz37etot0nNkq+1gTUy8R0vVJpsRQuvwrTSczXRWy7mkA@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
>> I am not sure about the '\n' you unconditionally added at the end of the
>> existing message.
>
> Right, the old code does that when the merge fails, counting on (I
> think) git-commit to then take care of any extra newlines.
Ahh, that explains it. I was originally about to suggest running the
stripspace() only when we run the editor, and saw a failure from an
unrelated test and realized that running stripspace() on the result of
prepare-commit-msg is the right thing to do after all, because that is
what is done by "git commit". Yes, the current code does rely on the
stripspace to remove it, so there is no need to make it conditional.
So if we drop the "conditionally add '\n'" part in builtin/merge.c from my
"how about this on top" patch and we should be ready to go, right?
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/7] Provide API to invalidate refs cache
From: Junio C Hamano @ 2011-10-11 0:02 UTC (permalink / raw)
To: Michael Haggerty
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland
In-Reply-To: <1318235064-25915-1-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> These patches apply on top of mh/iterate-refs, which is in next but
> not in master.
Building your series on mh/iterate-refs would unfortunately make the
conflict resolution worse. It would have been better if this were based on
a merge between mh/iterate-refs and jp/get-ref-dir-unsorted (which already
has happened on 'master' as of fifteen minutes ago).
I could rebase your series, but it always is more error prone to have
somebody who is not the original author rebase a series than the original
author build for the intended base tree from the beginning.
Thanks.
^ permalink raw reply
* Re: [PATCH v3] Teach merge the '[-e|--edit]' option
From: Jay Soffian @ 2011-10-11 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Todd A. Jacobs
In-Reply-To: <7v1uukieh2.fsf@alter.siamese.dyndns.org>
On Mon, Oct 10, 2011 at 5:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
> So if we drop the "conditionally add '\n'" part in builtin/merge.c from my
> "how about this on top" patch and we should be ready to go, right?
Yes. I can send a followup patch adding an additional test case next
week (for the case where the editor zeros out the message).
Thanks Junio!
j.
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Robin H. Johnson @ 2011-10-11 0:38 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List; +Cc: Robin H. Johnson, Michael J Gruber
In-Reply-To: <7vmxd9pxd2.fsf@alter.siamese.dyndns.org>
On Sun, Oct 09, 2011 at 04:18:49PM -0700, Junio C Hamano wrote:
> "Robin H. Johnson" <robbat2@gentoo.org> writes:
> > Workflow example:
> > 1. Dev1 creates a commit, signs it, pushes to central repo.
> > 2. Dev2 pulls, signs the tip commit, pushes it back.
>
> I personally am not sympathetic to such a "sign every and all commits by
> multiple people" workflow. If you really want to do such a thing, you can
> have the second and subsequent one to create a new commit on top whose
> sole purpose is to hold such a signature (commit --allow-empty --gpg-sig),
> or use signed tags.
For this case, I think having the push certificates works much better.
No easy solution to all of this, just lots of yak-shaving :-(.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply
* What's cooking snapshot
From: Junio C Hamano @ 2011-10-11 3:25 UTC (permalink / raw)
To: git
I am planning to merge the following topics that are queued in 'pu' to
'next' soonish.
* tm/completion-commit-fixup-squash (2011-10-06) 2 commits
- completion: commit --fixup and --squash
- completion: unite --reuse-message and --reedit-message handling
(this branch is used by sg/completion.)
* tm/completion-push-set-upstream (2011-10-06) 1 commit
- completion: push --set-upstream
* bc/attr-ignore-case (2011-10-06) 5 commits
- attr.c: respect core.ignorecase when matching attribute patterns
- attr: read core.attributesfile from git_default_core_config
- builtin/mv.c: plug miniscule memory leak
- cleanup: use internal memory allocation wrapper functions everywhere
- attr.c: avoid inappropriate access to strbuf "buf" member
* ef/mingw-syslog (2011-10-07) 1 commit
- mingw: avoid using strbuf in syslog
* jk/name-hash-dirent (2011-10-07) 1 commit
- fix phantom untracked files when core.ignorecase is set
* rs/pickaxe (2011-10-07) 7 commits
- pickaxe: factor out pickaxe
- pickaxe: give diff_grep the same signature as has_changes
- pickaxe: pass diff_options to contains and has_changes
- pickaxe: factor out has_changes
- pickaxe: plug regex/kws leak
- pickaxe: plug regex leak
- pickaxe: plug diff filespec leak with empty needle
* tc/fetch-leak (2011-10-07) 1 commit
- fetch: plug two leaks on error exit in store_updated_refs
* mm/maint-config-explicit-bool-display (2011-10-10) 1 commit
- config: display key_delim for config --bool --get-regexp
* rs/diff-whole-function (2011-10-10) 2 commits
- diff: add option to show whole functions as context
- xdiff: factor out get_func_line()
* sc/difftool-skip (2011-10-10) 1 commit
- git-difftool: allow skipping file by typing 'n' at prompt
* sg/completion (2011-10-10) 2 commits
- completion: unite --format and --pretty for 'log' and 'show'
- completion: unite --reuse-message and --reedit-message for 'notes'
(this branch uses tm/completion-commit-fixup-squash.)
Comments welcome.
^ permalink raw reply
* Re: [PATCH v3 5/5] attr.c: respect core.ignorecase when matching attribute patterns
From: Michael Haggerty @ 2011-10-11 3:44 UTC (permalink / raw)
To: Brandon Casey; +Cc: Brandon Casey, gitster, git, peff, j.sixt
In-Reply-To: <CA+sFfMd9exQcGfTGLJFPXG3-bq-ukn7K4m1R=LvLKqc1-jDVQw@mail.gmail.com>
On 10/10/2011 08:01 PM, Brandon Casey wrote:
> On Sun, Oct 9, 2011 at 10:16 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Maybe my commit message is not clear that it is describing the current
> behavior and not defining it. Instead of
>
> git should only match the portion of the path below the directory
> holding the .gitignore file according to the setting of
> core.ignorecase.
>
> maybe I should say
>
> git will currently only match the portion of the path...
>
> I could also remove the following test from the CASE_INSENSITIVE_FS
> tests since it is really a dontcare:
>
> attr_check A/b/h a/b/h "-c core.ignorecase=0"
>
> We don't care what happens when the user supplies A/b/h and a/b/h
> exists on disk when core.ignorecase=0, we only care that A/b/h is
> interpreted correctly when core.ignorecase=1.
Sounds good to me.
Thanks,
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 6/6] Retain caches of submodule refs
From: Michael Haggerty @ 2011-10-11 4:12 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, git, Jeff King, Drew Northup, Jakub Narebski
In-Reply-To: <20111010195325.GA5981@sandbox-rc>
On 10/10/2011 09:53 PM, Heiko Voigt wrote:
> On Sun, Oct 09, 2011 at 01:12:20PM +0200, Michael Haggerty wrote:
> Since the setup_revision() api can currently not be used to safely
> iterate twice over the same submodule my patch
>
> allow multiple calls to submodule merge search for the same path
>
> rewrites the search into using a child process. AFAIK the submodule ref
> iteration api would then even be unused.
If your patch is accepted, then we should check whether anything should
be ripped out.
> At least in my code there is no place where a submodule ref is changed.
> I only used it for merging submodule which only modifies the main
> module. So I would say its currently safe to assume that submodule refs
> do not get modified. If we do need that later on we can still add
> invalidation for submodule refs.
OK, thanks!
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v2 0/7] Provide API to invalidate refs cache
From: Michael Haggerty @ 2011-10-11 5:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips, Martin Fick, Christian Couder,
Christian Couder, Thomas Rast
In-Reply-To: <7vty7ggzum.fsf@alter.siamese.dyndns.org>
On 10/11/2011 02:02 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> These patches apply on top of mh/iterate-refs, which is in next but
>> not in master.
>
> Building your series on mh/iterate-refs would unfortunately make the
> conflict resolution worse. It would have been better if this were based on
> a merge between mh/iterate-refs and jp/get-ref-dir-unsorted (which already
> has happened on 'master' as of fifteen minutes ago).
AAAAaaaarrrgghh did that really have to happen?!?
> I could rebase your series, but it always is more error prone to have
> somebody who is not the original author rebase a series than the original
> author build for the intended base tree from the beginning.
I don't mind rebasing this little series on jp/get-ref-dir-unsorted.
But it's going to be an utter nightmare (as in, "can I even muster the
energy to do so much pointless work") to rebase my much bigger
hierarchical-refs series [1] onto jp/get-ref-dir-unsorted. The latter
makes changes all over refs.c and changes several things at once
(separate ref_entry out of ref_list, change current_ref to a ref_entry*,
rename ref_list to ref_array, change data structure to array plus
rewrite all loops, change to binary search). And
jp/get-ref-dir-unsorted includes a change that was inspired by my patch
series [2], so it is not like jp/get-ref-dir-unsorted was developed in
complete isolation from hierarchical-refs.
And this rebase will be work with no benefit, because my series includes
all of the improvements of jp/get-ref-dir-unsorted plus much more. But
my change to the data structure is implemented in a different order and
following other improvements. For example, I add a lot of comments,
change a lot of code to use the cached_refs data structure more
consistently, and accommodate partly-sorted lists by the time my patch
series includes everything that is in jp/get-ref-dir-unsorted.
Rebasing 78 patches is going to be a morass of clerical work. Is there
any alternative?
Michael
PS: I see that some confusion might have been caused by one of my emails
[3], where I mistakenly approved of the merge of jp/get-ref-dir-unsorted
(meaning the "Don't sort ref_list too early" part) just before asking
that jp/get-ref-dir-unsorted not be merged (meaning the rest). So maybe
I brought this whole mess down on my own head :-(
[1] branch hierarchical-refs on git://github.com/mhagger/git.git
[2] http://marc.info/?l=git&m=131740585620461&w=2
[3] http://marc.info/?l=git&m=131753257824405&w=2
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v2 1/7] invalidate_ref_cache(): rename function from invalidate_cached_refs()
From: Michael Haggerty @ 2011-10-11 5:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland
In-Reply-To: <7vfwj0iehl.fsf@alter.siamese.dyndns.org>
On 10/11/2011 02:00 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> It is the cache that is being invalidated, not the references.
>>
>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>> ---
>
> Although I think one can say "ref cache is the container for cached refs"
> and invalidating the "ref cache" as the container and invalidating the
> "cached refs" as a collection mean essentially the same thing, probably
> the new name makes more sense.
I certainly didn't mean to imply that the old name was incorrect. I
just think that the new name removes a tiny bit of ambiguity.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Michael J Gruber @ 2011-10-11 6:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa98okwl.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 10.10.2011 18:45:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> What norm? --amend keeps some header fields and discards others. In
>> fact, signing a commit "without changing it" (i.e. keeping tree, parents
>> etc., alias "--amend -C HEAD") should be the normal use case for signing
>> the tip of an existing branch. I mean, I have no problems adding to this:
>>
>> git help fixup
>> `git fixup' is aliased to `commit --amend -C HEAD'
>
> You are *additionally* saying "-C HEAD" in an non-standard alias. Isn't
> that enough indication that a vanila "--amend" is intended to record the
> commit based on the updated context in which the new commit is made?
> E.g. the authorship of the patch is still the same but committer
> information is updated.
I was more referring to leaving "parent" and "tree" headers in place,
which is a bit of a screwed comparison (because it relies on an
unchanged index).
>> But what is the best default for the workflows that we encourage (commit
>> early, ...)? You answer a pull-request which happens to be a
>> fast-forward, sign the tip and suddenly you've taken over ownership (and
>> changed dates)??? Signing a commit should not do this.
>
> I personally think a pull that is made in response to a pull-request,
> i.e. the upstream merging from lieutenant, especially when the
> authenticity of the puller matters, is perfectly fine with --no-ff.
Yeah, --no-ff would work. I guess we should find out what our "main
customers" need here, since our own patch-based workflow is irrelevant,
and either approach works with our "single push authority". Seems
--no-ff is an easy solution to multiple sigs.
> Unlike the sign-less "we together made these history and nobody really
> owns the result" (aka "Linus hates --no-ff merge because people do that to
> leave a mark by peeing in the snow, without adding anything of value in
> the history"), the whole purpose of signing a commit in the scenario you
> mentioned is for the puller to leave his mark in the history.
diff --git i/Documentation/merge-options.txt
w/Documentation/merge-options.txt
index b613d4e..74d6a05 100644
--- i/Documentation/merge-options.txt
+++ w/Documentation/merge-options.txt
@@ -7,6 +7,13 @@ With --no-commit perform the merge but pretend the merge
failed and do not autocommit, to give the user a chance to
inspect and further tweak the merge result before committing.
+--pee::
+--no-pee::
+ This activates `--commit` and `--no-ff` and passes
+ `--gpg-sign` to `commit`.
++
+Use `--no-pee` if you do not want or need to pee.
+
--ff::
--no-ff::
Do not generate a merge commit if the merge resolved as
:)
Michael
^ permalink raw reply related
* Re: [PATCH 0/9] i18n: add PO files to po/
From: Peter Krefting @ 2011-10-11 7:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Jonathan Nieder,
Git Mailing List, Ramkumar Ramachandra, Marcin Cieślak,
Sam Reed, Jan Engelhardt, Jan Krüger,
Nguyễn Thái Ngọc
In-Reply-To: <alpine.DEB.2.00.1110061025590.18528@ds9.cixit.se>
Peter Krefting:
> I have experience working with Translation Project, both as a software
> maintainer requesting translation, and as a translator doing translations,
> and I am interested in setting up a po repository for Git and use TP to
> maintain translations (or directly, for those that would prefer that).
I have now extracted the po/ directory from Ævar's ab/i18n branch and made
them available in a repository on Github: https://github.com/nafmo/git-po
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH v2 0/7] Provide API to invalidate refs cache
From: Julian Phillips @ 2011-10-11 8:09 UTC (permalink / raw)
To: Michael Haggerty
Cc: Junio C Hamano, git, Jeff King, Drew Northup, Jakub Narebski,
Heiko Voigt, Johan Herland, Martin Fick, Christian Couder,
Christian Couder, Thomas Rast
In-Reply-To: <4E93D932.6020001@alum.mit.edu>
On Tue, 11 Oct 2011 07:50:42 +0200, Michael Haggerty wrote:
> And this rebase will be work with no benefit, because my series
> includes
> all of the improvements of jp/get-ref-dir-unsorted plus much more.
> But
> my change to the data structure is implemented in a different order
> and
> following other improvements. For example, I add a lot of comments,
> change a lot of code to use the cached_refs data structure more
> consistently, and accommodate partly-sorted lists by the time my
> patch
> series includes everything that is in jp/get-ref-dir-unsorted.
>
> Rebasing 78 patches is going to be a morass of clerical work. Is
> there
> any alternative?
If you create a new commit that reverts the problematic changes to
refs.c with some suitable message about doing the same thing more
piecemeal as the first change of a new series, and rebase your changes
on top, you should be able to create a 79 patch series with little work.
Dunno if that would acceptable for merging?
--
Julian
^ permalink raw reply
* Re: [PATCH 2/2] submodule::module_clone(): silence die() message from module_name()
From: Tay Ray Chuan @ 2011-10-11 8:44 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git, Junio C Hamano, David Aguilar
In-Reply-To: <4E9348A8.5000500@web.de>
On Tue, Oct 11, 2011 at 3:34 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> BTW: this patch applies to next
>
> Am 07.10.2011 11:04, schrieb Tay Ray Chuan:
>> The die() message that may occur in module_name() is not really relevant
>> to the user when called from module_clone(); the latter handles the
>> "failure" (no submodule mapping) anyway.
>
> Makes tons of sense, especially as adding a new submodule currently always
> spews out the "No submodule mapping found in .gitmodules for path 'sub'"
> message right before that mapping is added there. Thanks for noticing that
> and ACK on that change from my side.
Thanks for the review.
>> Leave other callers of module_name() unchanged, as the die() message
>> shown is either relevant for user consumption (such as those that exit()
>> when the call fails), or will not occur at all (when called with paths
>> returned by module_list()).
>
> Hmm, while I agree on the first reasoning I'm not sure about the second.
> module_list() asks the index for the submodule paths while module_name()
> gets it's input from .gitmodules, so they can (and sometimes will)
> disagree.
Oh, you're right. I neglected to see how module_list() actually worked.
> When cmd_foreach() passes an empty "name" variable to the
> spawned command that might still work (and even make sense), but using the
> empty name in cmd_sync() to access the config is looking like an error to
> me. It might make sense to add an "|| exit" at least to the callsite in
> cmd_sync(). Or am I missing something here?
Cc-ed David, who authored cmd_sync().
David, what do you think of Jens' analysis?
In the meantime, I'll probably reword the second paragraph to say that
future work will be needed to analyze non- || exit callsites.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Submodule confusion when checking out branch
From: Howard Miller @ 2011-10-11 9:38 UTC (permalink / raw)
To: git
I added a submodule to my project like this (all from the root of the project)
git submodule add git@..... path/to/submodule
git submodule init
git add path/to/submodule
git commit -m 'I added a submodule!'
git push
All looks good and 'git status' reports 'nothing to commit'
However, I now cannot change branches. On checkout, I get...
"error: The following untracked working tree files would be
overwritten by checkout:"
(followed by a big list of all the files in the submodule)
Where did I go wrong and what can I do to sort it?
Thanks again!
^ permalink raw reply
* [PATCH] Improving performance with pthreads in refresh_index().
From: klinkert @ 2011-10-11 9:32 UTC (permalink / raw)
To: gitster; +Cc: git
Git performs for every file in a repository at least one (with a cold cache)
lstat(). In larger repositories operations like git status take a
long time. In case your local repository is located on a remote server
(e. g. mounted via nfs) it ends up in an *incredible* slow git.
With this patch you're able to determine a number of threads (maxthreads)
in your config file to run these tons of lstats in threads. There
won't be created any pthreads if you haven't set maxthreads. In my
test cases a git status with this patch performs enormously faster (over
two minutes before and approximately 25 seconds now). Of course, it
has a positive impact on other git commands, too.
Signed-off-by: Simon Klinkert <klinkert@webgods.de>
---
attr.c | 22 +++++++++
cache.h | 1 +
config.c | 5 ++
environment.c | 1 +
read-cache.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++++-------
5 files changed, 151 insertions(+), 18 deletions(-)
diff --git a/attr.c b/attr.c
index 33cb4e4..d296fe8 100644
--- a/attr.c
+++ b/attr.c
@@ -8,10 +8,14 @@
*/
#define NO_THE_INDEX_COMPATIBILITY_MACROS
+#include <pthread.h>
+#undef _FILE_OFFSET_BITS
#include "cache.h"
#include "exec_cmd.h"
#include "attr.h"
+pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
+
const char git_attr__true[] = "(builtin)true";
const char git_attr__false[] = "\0(builtin)false";
static const char git_attr__unknown[] = "(builtin)unknown";
@@ -748,6 +752,9 @@ int git_check_attr(const char *path, int num, struct git_attr_check *check)
{
int i;
+ if (max_threads)
+ pthread_mutex_lock(&mutex);
+
collect_all_attrs(path);
for (i = 0; i < num; i++) {
@@ -757,6 +764,9 @@ int git_check_attr(const char *path, int num, struct git_attr_check *check)
check[i].value = value;
}
+ if (max_threads)
+ pthread_mutex_unlock(&mutex);
+
return 0;
}
@@ -764,6 +774,9 @@ int git_all_attrs(const char *path, int *num, struct git_attr_check **check)
{
int i, count, j;
+ if (max_threads)
+ pthread_mutex_lock(&mutex);
+
collect_all_attrs(path);
/* Count the number of attributes that are set. */
@@ -785,6 +798,9 @@ int git_all_attrs(const char *path, int *num, struct git_attr_check **check)
}
}
+ if (max_threads)
+ pthread_mutex_unlock(&mutex);
+
return 0;
}
@@ -795,8 +811,14 @@ void git_attr_set_direction(enum git_attr_direction new, struct index_state *ist
if (is_bare_repository() && new != GIT_ATTR_INDEX)
die("BUG: non-INDEX attr direction in a bare repo");
+ if (max_threads)
+ pthread_mutex_lock(&mutex);
+
direction = new;
if (new != old)
drop_attr_stack();
use_index = istate;
+
+ if (max_threads)
+ pthread_mutex_unlock(&mutex);
}
diff --git a/cache.h b/cache.h
index 607c2ea..ab1b3e4 100644
--- a/cache.h
+++ b/cache.h
@@ -600,6 +600,7 @@ extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
extern int core_apply_sparse_checkout;
+extern int max_threads;
enum branch_track {
BRANCH_TRACK_UNSPECIFIED = -1,
diff --git a/config.c b/config.c
index 4183f80..24de139 100644
--- a/config.c
+++ b/config.c
@@ -466,6 +466,11 @@ int git_config_pathname(const char **dest, const char *var, const char *value)
static int git_default_core_config(const char *var, const char *value)
{
+ if (!strcmp(var, "core.maxthreads")) {
+ max_threads = git_config_int(var, value);
+ return 0;
+ }
+
/* This needs a better name */
if (!strcmp(var, "core.filemode")) {
trust_executable_bit = git_config_bool(var, value);
diff --git a/environment.c b/environment.c
index e96edcf..8bca4d5 100644
--- a/environment.c
+++ b/environment.c
@@ -59,6 +59,7 @@ char *notes_ref_name;
int grafts_replace_parents = 1;
int core_apply_sparse_checkout;
struct startup_info *startup_info;
+int max_threads = 1;
/* Parallel index stat data preload? */
int core_preload_index = 0;
diff --git a/read-cache.c b/read-cache.c
index 01a0e25..350bf4b 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -5,6 +5,8 @@
*/
#define NO_THE_INDEX_COMPATIBILITY_MACROS
#include "cache.h"
+#undef _FILE_OFFSET_BITS
+#include <pthread.h>
#include "cache-tree.h"
#include "refs.h"
#include "dir.h"
@@ -13,6 +15,8 @@
#include "blob.h"
#include "resolve-undo.h"
+pthread_mutex_t mutex_refresh_index = PTHREAD_MUTEX_INITIALIZER;
+
static struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really);
/* Index extensions.
@@ -1080,7 +1084,7 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
}
static void show_file(const char * fmt, const char * name, int in_porcelain,
- int * first, const char *header_msg)
+ int * first, char *header_msg)
{
if (in_porcelain && *first && header_msg) {
printf("%s\n", header_msg);
@@ -1089,45 +1093,96 @@ static void show_file(const char * fmt, const char * name, int in_porcelain,
printf(fmt, name);
}
-int refresh_index(struct index_state *istate, unsigned int flags, const char **pathspec,
- char *seen, const char *header_msg)
+struct t_ctx {
+ int flags;
+ int has_errors;
+ struct index_state *istate;
+ const char **pathspec;
+ char *seen, header_msg;
+
+ int tasks_done;
+} ctx;
+
+int
+thread_manager(void)
+{
+ if (max_threads)
+ pthread_mutex_lock(&mutex_refresh_index);
+
+ if (ctx.tasks_done >= ctx.istate->cache_nr) {
+ if (max_threads)
+ pthread_mutex_unlock(&mutex_refresh_index);
+ return -1;
+ }
+
+ int task = ctx.tasks_done++;
+
+ if (max_threads)
+ pthread_mutex_unlock(&mutex_refresh_index);
+
+ return task;
+}
+
+void *
+thread_refresh_index(void *p)
{
+ struct cache_entry *ce, *new;
+ int cache_errno = 0;
int i;
- int has_errors = 0;
+
+ while ((i = thread_manager()) != -1) {
+ struct index_state *istate = ctx.istate;
+ int flags = ctx.flags;
+
int really = (flags & REFRESH_REALLY) != 0;
int allow_unmerged = (flags & REFRESH_UNMERGED) != 0;
int quiet = (flags & REFRESH_QUIET) != 0;
int not_new = (flags & REFRESH_IGNORE_MISSING) != 0;
- int ignore_submodules = (flags & REFRESH_IGNORE_SUBMODULES) != 0;
+ int ignore_submodules =
+ (flags & REFRESH_IGNORE_SUBMODULES) != 0;
int first = 1;
int in_porcelain = (flags & REFRESH_IN_PORCELAIN);
unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
const char *needs_update_fmt;
const char *needs_merge_fmt;
- needs_update_fmt = (in_porcelain ? "M\t%s\n" : "%s: needs update\n");
- needs_merge_fmt = (in_porcelain ? "U\t%s\n" : "%s: needs merge\n");
- for (i = 0; i < istate->cache_nr; i++) {
- struct cache_entry *ce, *new;
- int cache_errno = 0;
+ needs_update_fmt =
+ (in_porcelain ? "M\t%s\n" : "%s: needs update\n");
+ needs_merge_fmt =
+ (in_porcelain ? "U\t%s\n" : "%s: needs merge\n");
ce = istate->cache[i];
- if (ignore_submodules && S_ISGITLINK(ce->ce_mode))
+ if (ignore_submodules && S_ISGITLINK(ce->ce_mode)) {
continue;
+ }
+
+ if (max_threads)
+ pthread_mutex_lock(&mutex_refresh_index);
if (ce_stage(ce)) {
while ((i < istate->cache_nr) &&
! strcmp(istate->cache[i]->name, ce->name))
i++;
i--;
- if (allow_unmerged)
+ if (allow_unmerged) {
+ if (max_threads)
+ pthread_mutex_unlock(&mutex_refresh_index);
continue;
- show_file(needs_merge_fmt, ce->name, in_porcelain, &first, header_msg);
- has_errors = 1;
+ }
+ show_file(needs_merge_fmt, ce->name, in_porcelain,
+ &first, &ctx.header_msg);
+ ctx.has_errors = 1;
+ if (max_threads)
+ pthread_mutex_unlock(&mutex_refresh_index);
continue;
}
- if (pathspec && !match_pathspec(pathspec, ce->name, strlen(ce->name), 0, seen))
+ if (max_threads)
+ pthread_mutex_unlock(&mutex_refresh_index);
+
+ if (ctx.pathspec && !match_pathspec(ctx.pathspec, ce->name,
+ strlen(ce->name), 0,
+ ctx.seen))
continue;
new = refresh_cache_ent(istate, ce, options, &cache_errno);
@@ -1145,14 +1200,63 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
}
if (quiet)
continue;
- show_file(needs_update_fmt, ce->name, in_porcelain, &first, header_msg);
- has_errors = 1;
+
+ if (max_threads)
+ pthread_mutex_lock(&mutex_refresh_index);
+
+ show_file(needs_update_fmt, ce->name, in_porcelain,
+ &first, &ctx.header_msg);
+
+ if (max_threads)
+ pthread_mutex_unlock(&mutex_refresh_index);
+
+ ctx.has_errors = 1;
continue;
}
replace_index_entry(istate, i, new);
}
- return has_errors;
+ return NULL;
+}
+
+int refresh_index(struct index_state *istate, unsigned int flags,
+ const char **pathspec, char *seen, const char *header_msg)
+{
+ int i;
+ int ret;
+ unsigned int created_threads = 0;
+
+ ctx.has_errors = 0;
+ ctx.tasks_done = 0;
+ ctx.istate = istate;
+ ctx.flags = flags;
+ ctx.pathspec = &pathspec[0];
+
+ if (istate->cache_nr < max_threads)
+ max_threads = istate->cache_nr;
+
+ if (max_threads > 1) {
+ pthread_t threads[max_threads];
+
+ /* create threads */
+ for (i = 0; i < max_threads; i++) {
+ ret = pthread_create(&threads[created_threads], NULL,
+ thread_refresh_index, NULL);
+ if (ret) {
+ printf("pthread_create failed ret=%d\n", ret);
+ break;
+ }
+ ++created_threads;
+ }
+
+ /* collect threads */
+ for (i = 0; i < created_threads; i++) {
+ ret = pthread_join(threads[i], NULL);
+ }
+ } else {
+ thread_refresh_index(NULL);
+ }
+ return ctx.has_errors;
}
static struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really)
--
1.7.7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox