* Re: [PATCH] Documentation: reorganize cvs-migration.txt
From: Junio C Hamano @ 2006-12-08 7:25 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20061208033400.GD30129@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> From 22e5bdd9de398f29dfb11125a0921bb4529e2ab7 Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>
> Date: Thu, 7 Dec 2006 22:32:28 -0500
> Subject: [PATCH] Documentation: simpler shared repository creation
>
> Take Johannes Schindelin's suggestion for a further simplification of the
> shared repository creation using git --bare init-db --shared.
>
> Also fix a mistake from the previous patch: I forgot to remove the manual setup
> which the --shared does for us.
>
> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
> ---
> Documentation/cvs-migration.txt | 27 ++++++++-------------------
> 1 files changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
> index 4fab0d7..20c5719 100644
Well, this does not apply at all, as I do not have a commit with
4fab0d7 blob and already applied the reordering patch from you.
Could you fix up and send again after I push out the latest? I
could try to coax into the documentation, but since I am not
even a CVS migrant myself and am known to be very bad at
documentation, I _really_ don't think you want me to do so.
;-)
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Alex Riesen @ 2006-12-08 7:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm9ynahc.fsf@assigned-by-dhcp.cox.net>
On 12/8/06, Junio C Hamano <junkio@cox.net> wrote:
> > yes, except that it'll compare the whole trees. Could I make it stop
> > at first mismatch? "-q|--quiet" for git-diff-index perhaps?
> > It's just not only stat, but also, open, read, mmap (yes, I try to use
> > it for packs) and close are really slow here as well.
>
> That sounds like optimizing for a wrong case -- you expect the
> index to match HEAD and trying to catch mistakes by detecting
> a mismatch, right?
I expect the index to differ from HEAD. The test is to avoid the mistake
of doing an empty commit.
> Having said that, I should point out that it is a low hanging
> fruit to optimize "diff-index --cached" for cases where index
> is expected to mostly match HEAD.
>
> The current code for "diff-index --cached" reads the whole tree
> into the index as stage #1 entries (diff-lib.c::run_diff_index),
> and then compares stage #0 (from the original index contents)
> and stage #1 (the tree parameter from the command line). Even
> if you stop at the first mismatch, you would already have paid
> the overhead to open and read all tree objects before even
> starting the comparison.
But I don't have to pay for the overhead of comparing all
entries, if I can stop at first mismatch and exit with non-0.
I think it'd make a difference (at least some difference).
But, if we could avoid loading of the entries which
will be never compared anyway, the speedup will be
of course more substantial...
> In 'pu' (jc/diff topic), I have a very generic code to walk the
> index, working tree and zero or more trees in parallel, taking
> advantage of cache-tree. If somebody is interested to learn the
> internals of git, some of the code could be lifted from there
> and simplified to walk just the index and a single tree, and I
> think that would optimize "diff-index --cached" quite a bit.
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Junio C Hamano @ 2006-12-08 7:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0612072327x77477584jb9131b26b0854f2@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
>> The current code for "diff-index --cached" reads the whole tree
>> into the index as stage #1 entries (diff-lib.c::run_diff_index),
>> and then compares stage #0 (from the original index contents)
>> and stage #1 (the tree parameter from the command line). Even
>> if you stop at the first mismatch, you would already have paid
>> the overhead to open and read all tree objects before even
>> starting the comparison.
>
> But I don't have to pay for the overhead of comparing all
> entries, if I can stop at first mismatch and exit with non-0.
Bench it if you doubt me.
I'd bet that the time spent in comparison between stages inside
index (and remember, you are not generating textual diff, only
comparing the SHA-1) is dwarfed by the overhead of populating
the stage #1 of the index with what is read from all the tree
objects.
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Alex Riesen @ 2006-12-08 7:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Randal L. Schwartz, git, Brian Gernhardt, Johannes Schindelin,
Pazu, Andreas Ericsson
In-Reply-To: <7virgnqpt5.fsf@assigned-by-dhcp.cox.net>
On 12/7/06, Junio C Hamano <junkio@cox.net> wrote:
> >> Definitely something went weird when Makefile was removed
> >> from .gitignore.
> >
> > Yes, perl/Makefile is getting overwritten by what Makefile.PL
> > generates. I thought the point of Alex's patch was to have it
> > muck with perl.mak and leave the tracked Makefile alone?
>
> Now, I am CLUELESS about what MakeMaker does, but would this
> help?
>
Much better.
Works here. Others?
> diff --git a/perl/Makefile.PL b/perl/Makefile.PL
> index de73235..4168775 100644
> --- a/perl/Makefile.PL
> +++ b/perl/Makefile.PL
> @@ -24,5 +24,6 @@ WriteMakefile(
> NAME => 'Git',
> VERSION_FROM => 'Git.pm',
> PM => \%pm,
> + MAKEFILE => 'perl.mak',
> %extra
> );
I should have read the FS of that MakeMaker.pm,
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Alex Riesen @ 2006-12-08 7:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcw6n8iz.fsf@assigned-by-dhcp.cox.net>
On 12/8/06, Junio C Hamano <junkio@cox.net> wrote:
> >> The current code for "diff-index --cached" reads the whole tree
> >> into the index as stage #1 entries (diff-lib.c::run_diff_index),
> >> and then compares stage #0 (from the original index contents)
> >> and stage #1 (the tree parameter from the command line). Even
> >> if you stop at the first mismatch, you would already have paid
> >> the overhead to open and read all tree objects before even
> >> starting the comparison.
> >
> > But I don't have to pay for the overhead of comparing all
> > entries, if I can stop at first mismatch and exit with non-0.
>
> Bench it if you doubt me.
I don't question that the overhead of comparing is very much
unnoticable. It just that it surely isn't zero, and it will grow with
the size of repo (linearly, right?)... And I am sure that this
repo will _only_ grow (typical corporate project).
> I'd bet that the time spent in comparison between stages inside
> index (and remember, you are not generating textual diff, only
> comparing the SHA-1) is dwarfed by the overhead of populating
> the stage #1 of the index with what is read from all the tree
> objects.
I already understood that. I just haven't found yet what can I do
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Alex Riesen @ 2006-12-08 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <81b0412b0612072327x77477584jb9131b26b0854f2@mail.gmail.com>
On 12/8/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 12/8/06, Junio C Hamano <junkio@cox.net> wrote:
> > In 'pu' (jc/diff topic), I have a very generic code to walk the
> > index, working tree and zero or more trees in parallel, taking
> > advantage of cache-tree. If somebody is interested to learn the
> > internals of git, some of the code could be lifted from there
> > and simplified to walk just the index and a single tree, and I
> > think that would optimize "diff-index --cached" quite a bit.
>
> Will try to look at it.
>
And now I'm playing with that (against test-para.c from pu).
I expect it to be broken by that webGmail, so it may not
apply to anything, but you'll get the idea. More clearly than
from me trying to explain.
commit 83642cdaca6dc1a2f94aa41923bc9e8f02d0e12f
Author: Alex Riesen <raa.lkml@gmail.com>
Date: Fri Dec 8 09:38:18 2006 +0100
add --quiet to test-para: stop at the first difference
diff --git a/test-para.c b/test-para.c
index bce5f0c..99d3792 100644
--- a/test-para.c
+++ b/test-para.c
@@ -21,6 +21,7 @@ int main(int ac, const char **av)
unsigned char trees[64][20];
int num_tree = 0, i, using_head, show_all = 0;
int index_wanted = 1, work_wanted = 1, tree_wanted = 0;
+ int quiet = 0;
const char *prefix;
const char **pathspec;
@@ -43,6 +44,8 @@ int main(int ac, const char **av)
work_wanted = 0;
else if (!strcmp(av[1] + 2, "no-index"))
index_wanted = 0;
+ else if (!strcmp(av[1] + 2, "quiet"))
+ quiet = 1;
else if (!av[1][2])
break;
else
@@ -118,7 +121,9 @@ int main(int ac, const char **av)
show_one(z, e->name, e->namelen,
e->hash, e->mode);
}
- else
+ else {
+ if (quiet)
+ exit(1);
for (i = 0; i < w.num_trees + 2; i++) {
char numbuf[10];
@@ -149,6 +154,7 @@ int main(int ac, const char **av)
show_one(z, e->name, e->namelen,
e->hash, e->mode);
}
+ }
}
^ permalink raw reply related
* Re: How to conver no branches/tags svn repo to git ?
From: Dongsheng Song @ 2006-12-08 8:52 UTC (permalink / raw)
To: git
In-Reply-To: <20061207195919.GA8179@localdomain>
Thanks,
---
Dongsheng Song
2006/12/8, Eric Wong <normalperson@yhbt.net>:
> Dongsheng Song <dongsheng.song@gmail.com> wrote:
> > e.g.
> > http://svn.berlios.de/viewcvs/open-iscsi/
> > http://svn.berlios.de/svnroot/repos/open-iscsi
>
> git svn init http://svn.berlios.de/svnroot/repos/open-iscsi
> git svn fetch
>
> --
> Eric Wong
^ permalink raw reply
* Re: For all you darcs lovers: git-hunk-commit
From: Matthias Kestenholz @ 2006-12-08 8:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612060129310.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Wed, 2006-12-06 at 01:36 +0100, Johannes Schindelin wrote:
> But in this case, bash was faster to script and debug, and unless people
> speak up, saying "I want that feature badly!", I do not plan to do
> anything with it.
This feature is _very_ handy and I think it would be great if this
became part of the default git distribution.
Thanks for writing this tool!
Matthias
^ permalink raw reply
* git-{fetch,pull} default behaviours (was Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone)
From: Francis Moreau @ 2006-12-08 9:03 UTC (permalink / raw)
To: andyparkins; +Cc: git
Andy Parkins wrote:
> Without any specification in the .git/config file, git-pull will execute
> "git-pull origin"; which in turn defaults to pull from the first "pull"
> definition for the remote, "origin".
>
> This is a difficult set of defaults to track for a new user, and it's
> difficult to see what tells git to do this (especially when it is
> actually hard-coded behaviour). To ameliorate this slightly, this patch
> explicitly specifies the default behaviour during a clone using the
> "branch" section of the config.
>
> For example, a clone of a typical repository would create a .git/config
> containing:
> [remote "origin"]
> url = proto://host/repo.git
> fetch = refs/heads/master:refs/remotes/origin/master
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> The [branch "master"] section is such that there is no change to the
> functionality of git-pull, but that functionality is now explicitly
> documented.
>
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> This is really to help newbies. By explicitly documenting the default
> behaviour, it makes it clearer what is going on. It also means no routing
> through documentation to find out what config option needs changing.
>
Well I would say that if you want newbies (like me) to understand
git-pull and git-fetch default behaviour, we should first fix their
documentations. I dunno if it's me but I really find it terrible to
read. A lot information are spread all across the doc and I haven't
found a logical organisation in it.
Just reading the synopsis of these two command at first glance does
not give a good view of the commands:
git-fetch <options> <repository> <refspec> ...
For example, it doesn't say that all arguments are optional at first
look, does it ? How does it say that I can run 'git-fetch origin' ?
When reading git-fetch doc, you find some specific git-pull
documentation which is confusing. The same is true when reading
git-pull doc. Why not removing all remote stuffs from git-pull doc and
just give a link to git-fetch for example ? Why not stopping using
git-pull word in git-fetch doc ?
I'm not sure that putting the default behaviour documentation in git's
config file will help the very newbie that I am. I expect to understand
how a command works in its documentation not by reading some git's
internal config file. And my first feeling when reading them is "whoa
this command seems really complex to use..."
However maybe explaining the default behaviour by giving some examples
would make things much more easier to understand. For example
Examples
--------
Running 'git-fetch' (without any arguments):
This is equivalent to run "git-fetch origin"....
Running 'git-fetch <repository>':
...
Running 'git-fetch <repository> <refspec>':
....
Running 'git-fetch <refspec>' (if possible):
...
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-08 9:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Kernel Org Admin, Git Mailing List, Petr Baudis
In-Reply-To: <Pine.LNX.4.64.0612071052560.3615@woody.osdl.org>
Linus Torvalds wrote:
[...]
> For example, if the git "refs/heads/" (or tags) directory hasn't changed
> in the last two months, we should probably set any ref-relative gitweb
> pages to have a caching timeout of a day or two. In contrast, if it's
> changed in the last hour, maybe we should only cache it for five minutes.
>
> Jakub: any way to make gitweb set the "expires" fields _much_ more
> aggressively. I think we should at least have the ability to set a basic
> rules like
>
> - a _minimum_ of five minutes regardless of anything else
>
> We might even tweak this based on loadaverage, and it might be
> worthwhile to add a randomization, to make sure that you don't get into
> situations where everything webpage needs to be recalculated at once.
I think the minimum expires (or minimum _additional_ expires: as of now
giweb only does expires +1d for explicit hash requests) should depend on
how often project changes. How often there are pushes to kernel.org?
> - if refs/ directories are old, raise the minimum by the age of the refs
>
> If it's more than an hour old, raise it to ten minutes. If it's more
> than a day, raise it to an hour. If it's more than a month old, raise
> it to a day. And if it's more than half a year, it's some historical
> archive like linux-history, and should probably default to a week or
> more.
What about packed refs?
We can certainly raise expires for tags (tags objects), as they should not
usually change.
> - infinite for stuff that isn't ref-related.
As sha1 is not changeable, everything that is accessed by explicit
sha1 (hash), or by explicit sha1 (hash_base) plus pathname (file_name)
should have effectively infinite expires.
Every caching would need some temporary memory, or temporary disk space.
And perhaps mod_perl specific caching would be useful here...
P.S. I have added Pasky to Cc:, as he manages http://repo.or.cz public
git repository hosting (much smaller than kernel.org and I think under less
load: but also I think withour kernel.org resources).
--
Jakub Narebski
^ permalink raw reply
* [PATCH] git-svn: extra error check to ensure we open a file correctly
From: Eric Wong @ 2006-12-08 9:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Randal L. Schwartz
In-Reply-To: <20061204181241.GA27342@soma>
This may be an issue with repositories imported with commit
27a1a8014b842c0d70fdc91c68dd361ca2dfb34c or later, but before
commit dad73c0bb9f33323ec1aacf560a6263f1d85f81a.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Eric Wong <normalperson@yhbt.net> wrote:
> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> > >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
> >
> > Eric> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> > >>
> > >> Does this ring a bell?
> >
> > Eric> Nope.
> >
> > Eric> This is on r15941 of https://svn.perl.org/parrot/trunk ? I can't seem
> > Eric> to reproduce this with git svn fetch -r15940:15941
> >
> > No, and that worked for me as well. Apparently, I might have corrupted my
> > metadata because I updated git-svn while I was using it. Is there any way to
> > reset the metadata without having to re-fetch 15000 revisions?
I fear I may have been looking in the wrong place while trying to
diagnose merlyn's problem. He did mention he was on a flaky connection
and that may have caused the corruption if he had one of those bad
versions.
git-svn.perl | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 747daf0..ff61b92 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3438,6 +3438,9 @@ sub open_file {
my ($self, $path, $pb, $rev) = @_;
my ($mode, $blob) = (safe_qx('git-ls-tree',$self->{c},'--',$path)
=~ /^(\d{6}) blob ([a-f\d]{40})\t/);
+ unless (defined $mode && defined $blob) {
+ die "$path was not found in commit $self->{c} (r$rev)\n";
+ }
{ path => $path, mode_a => $mode, mode_b => $mode, blob => $blob,
pool => SVN::Pool->new, action => 'M' };
}
--
1.4.4.1.g9c35e-dirty
^ permalink raw reply related
* Re: shallow clones, was Re: What's cooking in git.git (topics)
From: Aneesh Kumar K.V @ 2006-12-08 10:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612071557580.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>.
>> I'm not sure what reaction you expect, but this is something a lot of
>> our occasional Wine users are requesting. The Wine full history is 80Mb,
>> and that's a big download if you just want to try a quick patch. Now of
>> course you won't see these users around here hacking on shallow clone,
>> most likely they just went and downloaded Wine from the CVS mirror
>> instead. But it's a shame to have to maintain a CVS mirror just for that
>> purpose...
>
> Sorry, I was just mumbling about the fact that I would _like_ to hear back
> about successes and failures. If there are problems I want to fix them.
>
>>
How about this. This is already reported
kvaneesh@kvaneesh-laptop:/tmp$git clone --depth 2 /home/opensource/git git.test
.....
100% (743/743) done
kvaneesh@kvaneesh-laptop:/tmp$cd git.test/
[master@git.test]$ git fsck-objects
[master@git.test]$ git fetch --depth 4
remote: Generating pack...
remote: Done counting 872 objects.
...
100% (1/1) done
Total 1 (delta 0), reused 0 (delta 0)
Unpacking 1 objects
100% (1/1) done
[master@git.test]$ git fsck-objects
dangling commit aca085e577688108a2480b96a2f7077424a74e4d
dangling commit b360cca0b100e14abffa4cae78521b493c783738
dangling commit cd976f5c52694acb4b23c3f2425ed4f0a47ec799
^ permalink raw reply
* [PATCH] git-svn: use do_switch for --follow-parent if the SVN library supports it
From: Eric Wong @ 2006-12-08 10:20 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <20061207200236.GB8179@localdomain>
do_switch works with the SVN Perl bindings after r22312 in the
Subversion trunk. Since no released version of SVN currently
supports it; we'll just autodetect it and enable its usage
when a user has a recent-enough version of SVN.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Eric Wong <normalperson@yhbt.net> wrote:
> For the git-svn in master using the delta fetcher; there's no additional
> overhead to fetch properties. I want to ditch the old non-delta
> fetching code (it's only a mild performance benefit when using local
> repositories) if I could get do_switch() working correctly.
I don't think I can ditch the old code anytime soon. I was tempted to
try using do_diff, but it appears SVN downloads the entire files (using
get_file) and generates the diffs locally, negating any bandwidth
saving it would have over the libsvn_fetch_full() path.
git-svn.perl | 46 +++++++++++++++++++++++++++++++++++++++-------
1 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 747daf0..c907eb9 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -72,7 +72,7 @@ my ($_revision,$_stdin,$_no_ignore_ext,$_no_stop_copy,$_help,$_rmdir,$_edit,
$_username, $_config_dir, $_no_auth_cache, $_xfer_delta,
$_pager, $_color);
my (@_branch_from, %tree_map, %users, %rusers, %equiv);
-my ($_svn_co_url_revs, $_svn_pg_peg_revs);
+my ($_svn_co_url_revs, $_svn_pg_peg_revs, $_svn_can_do_switch);
my @repo_path_split_cache;
my %fc_opts = ( 'no-ignore-externals' => \$_no_ignore_ext,
@@ -2877,6 +2877,24 @@ sub libsvn_connect {
return $ra;
}
+sub libsvn_can_do_switch {
+ unless (defined $_svn_can_do_switch) {
+ my $pool = SVN::Pool->new;
+ my $rep = eval {
+ $SVN->do_switch(1, '', 0, $SVN->{url},
+ SVN::Delta::Editor->new, $pool);
+ };
+ if ($@) {
+ $_svn_can_do_switch = 0;
+ } else {
+ $rep->abort_report($pool);
+ $_svn_can_do_switch = 1;
+ }
+ $pool->clear;
+ }
+ $_svn_can_do_switch;
+}
+
sub libsvn_dup_ra {
my ($ra) = @_;
SVN::Ra->new(map { $_ => $ra->{$_} } qw/config url
@@ -3198,12 +3216,26 @@ sub libsvn_find_parent_branch {
unlink $GIT_SVN_INDEX;
print STDERR "Found branch parent: ($GIT_SVN) $parent\n";
sys(qw/git-read-tree/, $parent);
- # I can't seem to get do_switch() to work correctly with
- # the SWIG interface (TypeError when passing switch_url...),
- # so we'll unconditionally bypass the delta interface here
- # for now
- return libsvn_fetch_full($parent, $paths, $rev,
- $author, $date, $msg);
+ unless (libsvn_can_do_switch()) {
+ return libsvn_fetch_full($parent, $paths, $rev,
+ $author, $date, $msg);
+ }
+ # do_switch works with svn/trunk >= r22312, but that is not
+ # included with SVN 1.4.2 (the latest version at the moment),
+ # so we can't rely on it.
+ my $ra = libsvn_connect("$url/$branch_from");
+ my $ed = SVN::Git::Fetcher->new({c => $parent, q => $_q});
+ my $pool = SVN::Pool->new;
+ my $reporter = $ra->do_switch($rev, '', 1, $SVN->{url},
+ $ed, $pool);
+ my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef) : ();
+ $reporter->set_path('', $r0, 0, @lock, $pool);
+ $reporter->finish_report($pool);
+ $pool->clear;
+ unless ($ed->{git_commit_ok}) {
+ die "SVN connection failed somewhere...\n";
+ }
+ return libsvn_log_entry($rev, $author, $date, $msg, [$parent]);
}
print STDERR "Nope, branch point not imported or unknown\n";
return undef;
--
^ permalink raw reply related
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Jakub Narebski @ 2006-12-08 10:36 UTC (permalink / raw)
To: git
In-Reply-To: <200612071544.03306.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> However, as discussed in another thread, branch.*.merge currently has quite
> a strange semantic [*1*], and without changing, users have no way to grasp this
> configuration option.
[...]
> [*1*] Currently, in branch.*.merge you have to specify the remote branch name
> of a refspec which updates a local tracking branch in the fetch phase of git pull.
> I.e. the option value has nothing todo with the merge action itself!
That's (I think) because branch.<name>.merge can be for pull used _without_
tracking branch. So it is not that easy to change semantics, I agree bit
strange for newbie git users, who know git from the begining with
--use-separate-remote and tracking branches.
Perhaps we should extend it so it can take beginning part of refspec
(as now), full refspec, or ':' and local branch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [RFC/PATCH 0/5] WIP status/rerere reporting
From: Eric Wong @ 2006-12-08 10:49 UTC (permalink / raw)
To: git
In-Reply-To: <20061205092126.GE27236@soma>
This is the stuff I mentioned I had been working on several months
before in a reply to the git-explain/git-wtf/git-whatsup thread.
I've rebased it against the current master and everything still seems
to work (I don't have unit tests for them).
This has been forgotten and abandoned for a while. I especially don't
expect the changes to git-commit.sh (status) to be applied as-is, as it
should go into the new runstatus (my work predates runstatus).
git-am.sh | 18 ++++++++++++++----
git-commit.sh | 45 ++++++++++++++++++++++++++++++++++++++++++++-
git-rebase.sh | 43 ++++++++++++++++++++++++++++++-------------
git-rerere.perl | 25 +++++++++++++++++++++++++
4 files changed, 113 insertions(+), 18 deletions(-)
[PATCH 1/5] rerere: avoid misrecording on a skipped or aborted rebase/am
[PATCH 2/5] status: show files that would have resolutions recorded by rerere
[PATCH 3/5] am and rebase resolve states get picked up by status/commit
[PATCH 4/5] am: run git rerere to record resolution on successful --resolved
[PATCH 5/5] rerere: add the diff command
--
^ permalink raw reply
* [PATCH 1/5] rerere: avoid misrecording on a skipped or aborted rebase/am
From: Eric Wong @ 2006-12-08 10:49 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <20061205092126.GE27236@soma>
Data in rr-cache isn't valid after a patch application is
skipped or and aborted, so our next commit could be misrecorded
as a resolution of that skipped/failed commit, which is wrong.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-am.sh | 4 ++++
git-rebase.sh | 8 ++++++++
git-rerere.perl | 12 ++++++++++++
3 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index afe322b..28ccae3 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -246,6 +246,10 @@ last=`cat "$dotest/last"`
this=`cat "$dotest/next"`
if test "$skip" = t
then
+ if test -d "$GIT_DIR/rr-cache"
+ then
+ git-rerere clear
+ fi
this=`expr "$this" + 1`
resume=
fi
diff --git a/git-rebase.sh b/git-rebase.sh
index 25530df..2b4f347 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -139,6 +139,10 @@ do
--skip)
if test -d "$dotest"
then
+ if test -d "$GIT_DIR/rr-cache"
+ then
+ git-rerere clear
+ fi
prev_head="`cat $dotest/prev_head`"
end="`cat $dotest/end`"
msgnum="`cat $dotest/msgnum`"
@@ -157,6 +161,10 @@ do
exit
;;
--abort)
+ if test -d "$GIT_DIR/rr-cache"
+ then
+ git-rerere clear
+ fi
if test -d "$dotest"
then
rm -r "$dotest"
diff --git a/git-rerere.perl b/git-rerere.perl
index d3664ff..dd86577 100755
--- a/git-rerere.perl
+++ b/git-rerere.perl
@@ -172,6 +172,18 @@ sub merge {
-d "$rr_dir" || exit(0);
read_rr();
+
+if (@ARGV && $ARGV[0] eq 'clear') {
+ for my $path (keys %merge_rr) {
+ my $name = $merge_rr{$path};
+ if (-d "$rr_dir/$name") {
+ rmtree(["$rr_dir/$name"]);
+ }
+ }
+ unlink $merge_rr;
+ exit 0;
+}
+
my %conflict = map { $_ => 1 } find_conflict();
# MERGE_RR records paths with conflicts immediately after merge
--
1.4.4.2.g860f4
^ permalink raw reply related
* [PATCH 2/5] status: show files that would have resolutions recorded by rerere
From: Eric Wong @ 2006-12-08 10:49 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <20061205092126.GE27236@soma>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-commit.sh | 17 ++++++++++++++++-
git-rerere.perl | 18 ++++++++++++------
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 81c3a0c..9f6d1ef 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -48,7 +48,22 @@ run_status () {
GIT_INDEX_FILE="$NEXT_INDEX"
export GIT_INDEX_FILE
fi
-
+ if test -d "$GIT_DIR/rr-cache"
+ then
+ rr_shown=
+ git-rerere status | while read line; do
+ if [ -z "$rr_shown" ]; then
+ echo '#'
+ echo '# Resolutions to be recorded for files:'
+ echo '# (git-rerere will automatically record' \
+ 'conflict resolutions'
+ echo '# when these files are committed)'
+ echo '#'
+ rr_shown=1
+ fi
+ echo "# $line"
+ done
+ fi
case "$status_only" in
t) color= ;;
*) color=--nocolor ;;
diff --git a/git-rerere.perl b/git-rerere.perl
index dd86577..b78194a 100755
--- a/git-rerere.perl
+++ b/git-rerere.perl
@@ -173,14 +173,20 @@ sub merge {
read_rr();
-if (@ARGV && $ARGV[0] eq 'clear') {
- for my $path (keys %merge_rr) {
- my $name = $merge_rr{$path};
- if (-d "$rr_dir/$name") {
- rmtree(["$rr_dir/$name"]);
+if (my $arg = shift @ARGV) {
+ if ($arg eq 'clear') {
+ for my $path (keys %merge_rr) {
+ my $name = $merge_rr{$path};
+ if (-d "$rr_dir/$name") {
+ rmtree(["$rr_dir/$name"]);
+ }
+ }
+ unlink $merge_rr;
+ } elsif ($arg eq 'status') {
+ for my $path (keys %merge_rr) {
+ print $path, "\n";
}
}
- unlink $merge_rr;
exit 0;
}
--
1.4.4.2.g860f4
^ permalink raw reply related
* [PATCH 4/5] am: run git rerere to record resolution on successful --resolved
From: Eric Wong @ 2006-12-08 10:49 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <20061205092126.GE27236@soma>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-am.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 179b967..d0714c6 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -414,6 +414,10 @@ do
stop_here_user_resolve $this
fi
apply_status=0
+ if test -d "$GIT_DIR/rr-cache"
+ then
+ git rerere
+ fi
;;
esac
--
1.4.4.2.g860f4
^ permalink raw reply related
* [PATCH 3/5] am and rebase resolve states get picked up by status/commit
From: Eric Wong @ 2006-12-08 10:49 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <20061205092126.GE27236@soma>
This should help warn of accidental commits in the middle of a
rebase operation. It also saves messages in $dotest/resolvemsg
and shows it in "git status" so the user can be reminded of
how to continue the am or rebase operation.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-am.sh | 10 ++++++----
git-commit.sh | 28 ++++++++++++++++++++++++++++
git-rebase.sh | 35 ++++++++++++++++++++++-------------
3 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 28ccae3..179b967 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,7 +16,7 @@ stop_here () {
stop_here_user_resolve () {
if [ -n "$resolvemsg" ]; then
- echo "$resolvemsg"
+ echo "$resolvemsg" | tee "$dotest/resolvemsg"
stop_here $1
fi
cmdline=$(basename $0)
@@ -32,9 +32,11 @@ stop_here_user_resolve () {
then
cmdline="$cmdline -d=$dotest"
fi
- echo "When you have resolved this problem run \"$cmdline --resolved\"."
- echo "If you would prefer to skip this patch, instead run \"$cmdline --skip\"."
-
+ cat > "$dotest/resolvemsg" <<EOF
+When you have resolved this problem run \"$cmdline --resolved\".
+If you would prefer to skip this patch, instead run \"$cmdline --skip\".
+EOF
+ cat "$dotest/resolvemsg"
stop_here $1
}
diff --git a/git-commit.sh b/git-commit.sh
index 9f6d1ef..4691835 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -32,6 +32,33 @@ save_index () {
cp -p "$THIS_INDEX" "$NEXT_INDEX"
}
+check_dotest () {
+ if test -d .dotest
+ then
+ echo ''
+ if test -f .dotest/resolvemsg
+ then
+ cat .dotest/resolvemsg
+ else
+ echo 'A .dotest directory exists.'
+ echo 'Either a "git rebase" or "git am"' \
+ 'operation is in progress'
+ fi
+ fi
+ if test -d "$GIT_DIR/.dotest-merge"
+ then
+ echo ''
+ if test -f "$GIT_DIR/.dotest-merge/resolvemsg"
+ then
+ cat "$GIT_DIR/.dotest-merge/resolvemsg"
+ else
+ echo "A $GIT_DIR/.dotest-merge/resolvemsg " \
+ 'directory exists.'
+ echo 'A "git rebase --merge" operation is in progress'
+ fi
+ fi
+}
+
run_status () {
# If TMP_INDEX is defined, that means we are doing
# "--only" partial commit, and that index file is used
@@ -64,6 +91,7 @@ run_status () {
echo "# $line"
done
fi
+ check_dotest | sed -e 's/^/# /'
case "$status_only" in
t) color= ;;
*) color=--nocolor ;;
diff --git a/git-rebase.sh b/git-rebase.sh
index 2b4f347..53f3919 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -41,6 +41,16 @@ dotest=$GIT_DIR/.dotest-merge
prec=4
verbose=
+die_msg () {
+ > "$dotest/resolvemsg"
+ for i in "$@"
+ do
+ echo "$i" | tee -a "$dotest/resolvemsg" >&2
+ done
+ echo "$RESOLVEMSG" >> "$dotest/resolvemsg"
+ die "$RESOLVEMSG"
+}
+
continue_merge () {
test -n "$prev_head" || die "prev_head must be defined"
test -d "$dotest" || die "$dotest directory does not exist"
@@ -48,18 +58,17 @@ continue_merge () {
unmerged=$(git-ls-files -u)
if test -n "$unmerged"
then
- echo "You still have unmerged paths in your index"
- echo "did you forget update-index?"
- die "$RESOLVEMSG"
+ die_msg "You still have unmerged paths in your index" \
+ "did you forget update-index?"
fi
if test -n "`git-diff-index HEAD`"
then
if ! git-commit -C "`cat $dotest/current`"
then
- echo "Commit failed, please do not call \"git commit\""
- echo "directly, but instead do one of the following: "
- die "$RESOLVEMSG"
+ die_msg \
+ "Commit failed, please do not call \"git commit\"" \
+ "directly, but instead do one of the following: "
fi
printf "Committed: %0${prec}d" $msgnum
else
@@ -73,6 +82,7 @@ continue_merge () {
echo "$prev_head" > "$dotest/prev_head"
# onto the next patch:
+ rm -f "$dotest/resolvemsg"
msgnum=$(($msgnum + 1))
echo "$msgnum" >"$dotest/msgnum"
}
@@ -88,14 +98,13 @@ call_merge () {
;;
1)
test -d "$GIT_DIR/rr-cache" && git-rerere
- die "$RESOLVEMSG"
+ die_msg
;;
2)
- echo "Strategy: $rv $strategy failed, try another" 1>&2
- die "$RESOLVEMSG"
+ die_msg "Strategy: $rv $strategy failed, try another"
;;
*)
- die "Unknown exit code ($rv) from command:" \
+ die_msg "Unknown exit code ($rv) from command:" \
"git-merge-$strategy $cmt^ -- HEAD $cmt"
;;
esac
@@ -112,9 +121,8 @@ do
--continue)
diff=$(git-diff-files)
case "$diff" in
- ?*) echo "You must edit all merge conflicts and then"
- echo "mark them as resolved using git update-index"
- exit 1
+ ?*) die_msg "You must edit all merge conflicts and then" \
+ "mark them as resolved using git update-index"
;;
esac
if test -d "$dotest"
@@ -143,6 +151,7 @@ do
then
git-rerere clear
fi
+ rm -f "$dotest/resolvemsg"
prev_head="`cat $dotest/prev_head`"
end="`cat $dotest/end`"
msgnum="`cat $dotest/msgnum`"
--
1.4.4.2.g860f4
^ permalink raw reply related
* [PATCH 5/5] rerere: add the diff command
From: Eric Wong @ 2006-12-08 10:49 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <20061205092126.GE27236@soma>
Sometimes I like to see what I'm recording resolutions for and
what's changed during a resolution.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-rerere.perl | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/git-rerere.perl b/git-rerere.perl
index b78194a..7a3ae84 100755
--- a/git-rerere.perl
+++ b/git-rerere.perl
@@ -186,6 +186,13 @@ if (my $arg = shift @ARGV) {
for my $path (keys %merge_rr) {
print $path, "\n";
}
+ } elsif ($arg eq 'diff') {
+ for my $path (keys %merge_rr) {
+ my $name = $merge_rr{$path};
+ system(qw/diff/, @ARGV,
+ '-L', "a/$path", '-L', "b/$path",
+ "$rr_dir/$name/preimage", $path);
+ }
}
exit 0;
}
--
1.4.4.2.g860f4
^ permalink raw reply related
* Documentation/git-commit.txt
From: Junio C Hamano @ 2006-12-08 11:20 UTC (permalink / raw)
To: git
I attempted to rewrite the git-commit documentation.
I think I went overboard and ended up not using the word
"index", but eradicating the word was not my intention. I think
we should hint how the index is used to implement the semantics
somewhere near the end where it is not distracting to ordinary
users but is accessbile by people who are interested in the
plumbing-Porcelain interface.
---
The following patch will _not_ apply as is, as I sprinkled a lot
of annotations in it, but you should be able to run
sed -e '/^|/d'
on it to make it apply if you want.
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 517a86b..50e8fd0 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -14,25 +14,111 @@ SYNOPSIS
DESCRIPTION
-----------
-Updates the index file for given paths, or all modified files if
-'-a' is specified, and makes a commit object. The command specified
-by either the VISUAL or EDITOR environment variables are used to edit
-the commit log message.
|
| General idea; (1) we do not have to say "index" in Porcelain-ish
| documentation. (2) we should have a separate ENVIRONMENT section
| at the end as all UNIX manpage does.
|
+Records a tree state as a new commit object. The command is
+used for both recording your own changes and recording the
+result of manual resolution of a conflicted merge.
+
+When recoring your own work, the contents of modified files in
+your working tree are staged with gitlink:git-add[1]. Removal
+of a file are staged with gitlink:git-rm[1]. After building the
+state to be committed incrementally with these commands, `git
+commit` (without any pathname parameter) is used to record what
+has been staged so far. This is the most basic form of the
+command. An example:
|
| Give examples early and abundance of them. Mention add and rm
| as staging commands; technically mv is also a staging command but
| this manpage is not about various ways to stage things, but
| making a commit out of staged state, so omit it.
|
+
+------------
+$ edit hello.c
+$ git rm goodbye.c
+$ git add hello.c
+$ git commit
+------------
+
+////////////
+We should fix 'git rm' to remove goodbye.c from both index and
+working tree for the above example.
+////////////
+
+Instead of staging files after each individual change, you can
+tell `git commit` to notice the changes to the tracked files in
+your working tree and do corresponding `git add` and `git rm`
+for you. That is, this example does the same as the earlier
+example if there is no other change in your working tree:
+
+------------
+$ edit hello.c
+$ rm goodbye.c
+$ git commit -a
+------------
+
+The command `git commit -a` first looks at your working tree,
+notices that you have modified hello.c and removed goodbye.c,
+and performs necessary `git add` and `git rm` for you.
+
+After staging changes to many files, you can alter the order the
+changes are recorded in, by giving pathnames to `git commit`.
+When pathnames are given, the command makes a commit that
+only records the changes made to the named paths:
+
+------------
+$ edit hello.c hello.h
+$ git add hello.c hello.h
+$ edit Makefile
+$ git commit Makefile
+------------
+
+This makes a commit that records the modification to `Makefile`.
+The changes staged for `hello.c` and `hello.h` are not included
+in the resulting commit. However, their changes are not lost --
+they are still staged and merely held back. After the above
+sequence, if you do:
+
+------------
+$ git commit
+------------
+
+this second commit would record the changes to `hello.c` and
+`hello.h` as expected.
+
+
+After a merge (initiated by either gitlink:git-merge[1] or
+gitlink:git-pull[1]) stops because of conflicts, cleanly merged
+paths are already staged to be committed for you, and paths that
+conflicted are left in unmerged state. You would have to first
+check which paths are conflicting with gitlink:git-ls-files[1]
+and after fixing them manually in your working tree, you would
+stage the result as usual with gitlink:git-add[1]:
+
+------------
+$ git ls-files -u
+100644 c87c61af00c6d2cd7212240e26089e24b90bbe05 1 hello.c
+100644 646b6e73318e04cfff7b20abd5d06be424bce503 2 hello.c
+100644 44b1ce4c6b56348e1661b60fc923cb80cb44d4ff 3 hello.c
+$ edit hello.c
+$ git add hello.c
+------------
|
| Obviously 'ls-files -u' is a plumbing so we might want to give an
| equivalent Porcelain. We could say 'git status' and have the
| reader look for "unmerged:", which might be better. I dunno.
|
+
+After resolving conflicts and staging the result, `git ls-files -u`
+would stop mentioning the conflicted path. When you are done,
+run `git commit` to finally record the merge:
+
+------------
+$ git commit
+------------
+
+As with the case to record your own changes, you can use `-a`
+option to save typing. One difference is that during a merge
+resolution, you cannot use `git commit` with pathnames to
+alter the order the changes are committed, because the merge
+should be recorded as a single commit. In fact, the command
+refuses to run when given pathnames (but see `-i` option).
|
| "con paths" form is really about 'alter the order of things
| that are committed', in other words 'you may have started
| staging but we let you split what is staged'. Once the reader
| understands it, it should be natural why we cannot use "paths"
| during a merge resolution.
|
-Several environment variable are used during commits. They are
-documented in gitlink:git-commit-tree[1].
-
-
-This command can run `commit-msg`, `pre-commit`, and
-`post-commit` hooks. See link:hooks.html[hooks] for more
-information.
|
| In addition to ENVIRONMENT, many Porcelain-ish can invoke
| hooks, and we should have HOOKS section at the same location
| across manpages so people can expect where to find them.
| I just chose them to be at the end.
|
OPTIONS
-------
-a|--all::
- Update all paths in the index file. This flag notices
- files that have been modified and deleted, but new files
- you have not told git about are not affected.
+ Tell the command to automatically stage files that have
+ been modified and deleted, but new files you have not
+ told git about are not affected.
|
| No need to say "index", although I do not think we should
| avoid the word.
|
-c or -C <commit>::
Take existing commit object, and reuse the log message
@@ -55,16 +141,13 @@ OPTIONS
-s|--signoff::
Add Signed-off-by line at the end of the commit message.
--v|--verify::
- Look for suspicious lines the commit introduces, and
- abort committing if there is one. The definition of
- 'suspicious lines' is currently the lines that has
- trailing whitespaces, and the lines whose indentation
- has a SP character immediately followed by a TAB
- character. This is the default.
-
--n|--no-verify::
- The opposite of `--verify`.
+--no-verify::
+ By default, the command looks for suspicious lines the
+ commit introduces, and aborts committing if there is one.
+ The definition of 'suspicious lines' is currently the
+ lines that has trailing whitespaces, and the lines whose
+ indentation has a SP character immediately followed by a
+ TAB character. This option turns off the check.
|
| The --verify option does not exist anymore. This is an independent fix.
| We do not yet describe --verbose (and real '-v') in the
| current page, which is quite BAD. It shows the diff between HEAD
| and what is being committed.
|
-e|--edit::
The message taken from file with `-F`, command line with
@@ -95,16 +177,16 @@ but can be used to amend a merge commit.
--
-i|--include::
- Instead of committing only the files specified on the
- command line, update them in the index file and then
- commit the whole index. This is the traditional
- behavior.
+ Before making a commit out of staged contents so far,
+ stage the contents of paths given on the command line
+ as well. This is usually not what you want unless you
+ are concluding a conflicted merge.
-o|--only::
- Commit only the files specified on the command line.
- This format cannot be used during a merge, nor when the
- index and the latest commit does not match on the
- specified paths to avoid confusion.
+ Commit only the files specified on the command line;
+ this is the default when pathnames are given on the
+ command line, so you usually do not have to give this
+ option. This format cannot be used during a merge.
\--::
Do not interpret any more arguments as options.
@@ -118,46 +200,16 @@ If you make a commit and then found a mistake immediately after
that, you can recover from it with gitlink:git-reset[1].
-Discussion
-----------
-
-`git commit` without _any_ parameter commits the tree structure
-recorded by the current index file. This is a whole-tree commit
-even the command is invoked from a subdirectory.
-
-`git commit --include paths...` is equivalent to
-
- git update-index --remove paths...
- git commit
-
-That is, update the specified paths to the index and then commit
-the whole tree.
-
-`git commit paths...` largely bypasses the index file and
-commits only the changes made to the specified paths. It has
-however several safety valves to prevent confusion.
-
-. It refuses to run during a merge (i.e. when
- `$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
- that the traditional semantics now needs -i flag.
-
-. It refuses to run if named `paths...` are different in HEAD
- and the index (ditto about reminding). Added paths are OK.
- This is because an earlier `git diff` (not `git diff HEAD`)
- would have shown the differences since the last `git
- update-index paths...` to the user, and an inexperienced user
- may mistakenly think that the changes between the index and
- the HEAD (i.e. earlier changes made before the last `git
- update-index paths...` was done) are not being committed.
-
-. It reads HEAD commit into a temporary index file, updates the
- specified `paths...` and makes a commit. At the same time,
- the real index file is also updated with the same `paths...`.
-
-`git commit --all` updates the index file with _all_ changes to
-the working tree, and makes a whole-tree commit, regardless of
-which subdirectory the command is invoked in.
|
| Lose this section that only talks about implementation detail
| and expect the readers to understand the behaviour from it.
| The audience when the page was originally written were well
| versed in plumbing and the above technical description
| conveyed what we wanted to say in very precise terms, but that
| was only because git was very young.
|
+ENVIRONMENT VARIABLES
+---------------------
+The command specified by either the VISUAL or EDITOR environment
+variables are used to edit the commit log message.
+HOOKS
+-----
+This command can run `commit-msg`, `pre-commit`, and
+`post-commit` hooks. See link:hooks.html[hooks] for more
+information.
Author
------
^ permalink raw reply related
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-08 11:25 UTC (permalink / raw)
To: git
In-Reply-To: <20061207235039.GA423@dspnet.fr.eu.org>
Olivier Galibert wrote:
> On Thu, Dec 07, 2006 at 11:57:34AM -0800, H. Peter Anvin wrote:
>> Olivier Galibert wrote:
>>>On Thu, Dec 07, 2006 at 11:16:58AM -0800, H. Peter Anvin wrote:
>>>>
>>>>Unfortunately, the most common queries are also extremely expensive.
>>>
>>>Do you have a top-ten of queries ? That would be the ones to optimize
>>>for.
>>
>> The front page, summary page of each project, and the RSS feed for each
>> project.
>
> Hmmm, maybe you could have the summaries and rss feed generated on
> push, which could also generate elementary files with lines of the
> front page. That would make these top offenders static page serving.
The "extremely aggresive caching solution" could be as follows: cache
everything, invalidate (remove) on push caches of variable variety related
to push (list of projects and OPML on any push; summary page and every
page without h=<hash> or hb=<hash>;f=<filename> for a given project).
The most important problem is that kernel.org uses old gitweb, the last
version before incorporating gitweb into git (and also reducing
significantly the time needed for summary, heads and tags pages).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Fix documentation copy&paste typo
From: Uwe Kleine-Koenig @ 2006-12-08 11:44 UTC (permalink / raw)
To: git; +Cc: Uwe Zeisberger
From: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
This was introduced in 45a3b12cfd3eaa05bbb0954790d5be5b8240a7b5
Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 093bd72..ed40810 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -120,7 +120,7 @@ our %feature = (
# To disable system wide have in $GITWEB_CONFIG
# $feature{'snapshot'}{'default'} = [undef];
# To have project specific config enable override in $GITWEB_CONFIG
- # $feature{'blame'}{'override'} = 1;
+ # $feature{'snapshot'}{'override'} = 1;
# and in project config gitweb.snapshot = none|gzip|bzip2;
'snapshot' => {
'sub' => \&feature_snapshot,
--
1.4.4.2.gb772
^ permalink raw reply related
* Re: git pull and merging.
From: Jakub Narebski @ 2006-12-08 11:48 UTC (permalink / raw)
To: git
In-Reply-To: <200612071227.46194.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> Now looking at it, I think this semantic really is screwed and utterly confusing.
> Why decides branch.*.merge about actions done in fetch (I think even if you did
> "git fetch" alone)? OK, actually, that is an implementation detail and not
> really important.
>
> More important: Because "branch.*.merge" specifies a _remote_ branch,
> the user has to understand that this info is already used in the fetch.
> The intuitive mental model of a user about how it works IMHO is that
> "branch.*.merge" is checked in the merge phase (as the name of the option suggests).
> But this way, how could the merge phase know about any remote branch at all,
> which does not need to be touched at all in the merge phase?
>
> IMHO we should somehow change the semantic of branch.*.merge to specify the _local_
> refspec part, as this is the branch which actually gets merged.
> This is the only way that a user could grasp the meaning of it.
> Perhaps introduce "branch.*.defaultmerge", and obsoleting "branch.*.merge"?
The change of semantic would prohibit the "pull without tracking branch"
semantic (probably not used anymore, since git supports multiple heads
from long time).
I proposed in another thread to allow to either specify full refspec (in
addition to current specifying remote branch), or ':' and local branch.
Or perhaps add branch.*.localmerge configuration option?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Brian Gernhardt @ 2006-12-08 11:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0612072340w6af9df37y25a1d15773a3f8d8@mail.gmail.com>
On Dec 8, 2006, at 2:40 AM, Alex Riesen wrote:
>> Now, I am CLUELESS about what MakeMaker does, but would this
>> help?
>
> Much better.
> Works here. Others?
Perfect!
^ permalink raw reply
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