* git-svnimport breakage as of git-1.4.4
From: Daniel Drake @ 2006-12-07 15:26 UTC (permalink / raw)
To: git; +Cc: sashak
Hi,
git-svnimport broken between git-1.4.3.5 and git-1.4.4
I have found that commit 83936a29e275bc0c04f60d3333e4951a9e16b1fc is the
cause of this.
I am using git-svnimport to work with a repo with this layout:
https://server/repo/trunk
https://server/repo/tags/x.y.z
https://server/repo/branches/somebranch
Starting a fresh import:
# git-svnimport -v -i -C repo -r https://server repo
Fetching from 1 to 10707 ...
Tree ID 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed change 1:/ 2004-12-22 22:53:27)
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Commit ID 2614c05ac4c5f24eb89cea056a7d46c909084d8c
Writing to refs/heads/origin
DONE: 1 origin 2614c05ac4c5f24eb89cea056a7d46c909084d8c
RA layer request failed: PROPFIND request failed on '/trunk/.cvsignore':
PROPFIND of '/trunk/.cvsignore': 405 Method Not Allowed (https://server)
at /usr/bin/git-svnimport line 358
According to the server logs, git is requesting /trunk/.cvsignore rather
than /repo/trunk/.cvsignore
I'm happy to test patches and whatnot but don't have time to investigate
further right now.
Thanks!
--
Daniel Drake
Brontes Technologies, A 3M Company
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Andreas Ericsson @ 2006-12-07 15:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Pearce, Marco Costalba, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0612071553090.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 7 Dec 2006, Andreas Ericsson wrote:
>
>> Shawn Pearce wrote:
>>> Perhaps there is some fast IPC API supported by Qt that you could use
>>> to run the revision listing outside of the main UI process, to
>>> eliminate the bottlenecks you are seeing and remove the problems noted
>>> above? One that doesn't involve reading from a pipe I mean...
>>>
>> Why not just fork() + exec() and read from the filedescriptor? You can
>> up the output buffer of the forked program to something suitable, which
>> means the OS will cache it for you until you copy it to a buffer in qgit
>> (i.e., read from the descriptor).
>
> Could somebody remind me why different processes are needed? I thought
> that the revision machinery should be used directly, by linking to
> libgit.a...
>
You wrote:
--%<--%<--%<--
Because, depending on what you do, the revision machinery is not
reentrable. For example, if you filter by filename, the history is
rewritten in-memory to simulate a history where just that filename was
tracked, and nothing else. These changes are not cleaned up after
calling the internal revision machinery.
--%<--%<--%<--
When I wrote the above suggestion, I hadn't read the posts following the
email where I cut this text from (where Linus said "we can add a 'reset'
thingie to the revision walking machinery" and Marco replied with some
more questions).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Brian Gernhardt @ 2006-12-07 15:29 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612071554180.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Alex Riesen wrote:
> Strange. You seem to have the old, generated Makefile you perl/
> directory. Haven't your pull failed?
My pull didn't fail, and your suggested list of commands tells me
"Already up-to-date." I've pulled, reset, and removed perl/Makefile
repeatedly when I was trying to use git-bisect. Primarily because of
merge conflicts in perl/Makefile that running make causes.
Johannes Schindeli wrote:
>> When I pulled the most recent changes for git (de51faf), `make` began
>> failing with the following messages: [...]
>
> I found the same, but could not reproduce it. But a "touch perl/
> perl.mak"
> fixes at least compilation.
Indeed, the following sequence works:
git reset --hard
touch perl/perl.mak
make
But this one doesn't:
git reset --hard
make
touch perl/perl.mak
make
That one fails with "make[2]: *** No rule to make target
`instlibdir'. Stop."
And both of these sequences cause `git status` to report that "perl/
Makefile" has been changed, which doesn't seem ideal.
(I'm replying to multiple messages because the list archive I'm
browsing is getting the messages faster than I am, and I didn't feel
the need to wait.)
^ permalink raw reply
* Re: Bug in merge-recursive in virtual commit corner case
From: Johannes Schindelin @ 2006-12-07 15:38 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061207083531.GA22701@spearce.org>
Hi,
On Thu, 7 Dec 2006, Shawn Pearce wrote:
> So I managed to create a fairly complex set of branches which are all
> merged back against each other at various points in time. Two of
> them have 3 merge bases according to git-merge-base. Tonight I
> tried to merge them together, but received the following wonderful
> error from git-merge-recursive:
>
> fatal: unable to read source tree (4b825dc642cb6eb9a060e54bf8d69288fbee4904)
>
> For those in the know, that's the empty tree. This particular
> repository does not have the empty tree anywhere in it, which is why we
> can't read the object: it doesn't exist, and shouldn't exist.
I think there is something else wrong. If you have three merge bases, I do
not see how you could get into that particular code path.
Any possibility for me to have a private look at your repo?
Ciao,
Dscho
^ permalink raw reply
* Re: Locked down (but still shared) repositories
From: Johannes Schindelin @ 2006-12-07 15:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061207113539.GA10781@spearce.org>
Hi,
On Thu, 7 Dec 2006, Shawn Pearce wrote:
> For various auditing reasons the repositories need to be tightly
> controlled. That is the following cannot be permitted:
>
> * delete or overwrite a loose object;
> * delete or overwrite a pack file;
> * delete or overwrite a ref, except see below;
> * change the config;
> * change the description;
> * change HEAD;
>
> [...]
>
> I also cannot create secondary git-only UNIX accounts for each user,
> using git-shell in the git-only account.
How about just one such user? After all, you already have this user: the
repo owner. Of course, people have to push via ssh, even on the same
machine.
Ciao,
Dscho
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Alex Riesen @ 2006-12-07 15:42 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <E8038C15-B359-4DE9-B3E0-45B065AEDBFA@silverinsanity.com>
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
Does the attached patch help? I highly suspect the perl.mak generated
by MakeMaker.
diff --git a/perl/Makefile b/perl/Makefile
index bd483b0..b936e0d 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -29,6 +29,8 @@ $(makfile): ../GIT-CFLAGS Makefile
echo ' echo $(instdir_SQ)' >> $@
else
$(makfile): Makefile.PL ../GIT-CFLAGS
+ $(RM) $(makfile)
+ $(RM) $(makfile).old
'$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
endif
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: perl.mak.old.patch --]
[-- Type: text/x-diff; name="perl.mak.old.patch", Size: 715 bytes --]
From 5e00f865fa13a425d4395a70aaca798dfaf093dc Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 7 Dec 2006 16:40:06 +0100
Subject: [PATCH] workaround for MakeMaker-generated Makefiles
It seems to try to mv perl.mak into perl.mak.old file without checking if
.old exists first.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
diff --git a/perl/Makefile b/perl/Makefile
index bd483b0..b936e0d 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -29,6 +29,8 @@ $(makfile): ../GIT-CFLAGS Makefile
echo ' echo $(instdir_SQ)' >> $@
else
$(makfile): Makefile.PL ../GIT-CFLAGS
+ $(RM) $(makfile)
+ $(RM) $(makfile).old
'$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
endif
^ permalink raw reply related
* Re: Fast access git-rev-list output: some OS knowledge required
From: Johannes Schindelin @ 2006-12-07 16:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn Pearce, Marco Costalba, Git Mailing List
In-Reply-To: <4578330C.9070208@op5.se>
Hi,
On Thu, 7 Dec 2006, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Thu, 7 Dec 2006, Andreas Ericsson wrote:
> >
> > > Shawn Pearce wrote:
> > > > Perhaps there is some fast IPC API supported by Qt that you could use to
> > > > run the revision listing outside of the main UI process, to eliminate
> > > > the bottlenecks you are seeing and remove the problems noted above? One
> > > > that doesn't involve reading from a pipe I mean...
> > > >
> > > Why not just fork() + exec() and read from the filedescriptor? You can up
> > > the output buffer of the forked program to something suitable, which means
> > > the OS will cache it for you until you copy it to a buffer in qgit (i.e.,
> > > read from the descriptor).
> >
> > Could somebody remind me why different processes are needed? I thought that
> > the revision machinery should be used directly, by linking to libgit.a...
> >
>
> You wrote:
> --%<--%<--%<--
> Because, depending on what you do, the revision machinery is not
> reentrable. For example, if you filter by filename, the history is
> rewritten in-memory to simulate a history where just that filename was
> tracked, and nothing else. These changes are not cleaned up after calling the
> internal revision machinery.
> --%<--%<--%<--
>
> When I wrote the above suggestion, I hadn't read the posts following the
> email where I cut this text from (where Linus said "we can add a 'reset'
> thingie to the revision walking machinery" and Marco replied with some
> more questions).
Yes. The reset thingie is already in place: clear_commit_marks(). It would
have to be enhanced a little, though:
1) the function rewrite_parents(), should add another flag, HALFORPHANED,
and
2) clear_commit_marks() should unset the "parsed" flag of the commits for
which HALFORPHANED is reset.
-- snip --
diff --git a/commit.c b/commit.c
index d5103cd..fd225c8 100644
--- a/commit.c
+++ b/commit.c
@@ -431,6 +431,10 @@ void clear_commit_marks(struct commit *commit, unsigned int mark)
{
struct commit_list *parents;
+ /* were parents rewritten? */
+ if ((mark & commit->object.flags) & HALFORPHANED)
+ commit->object.parsed = 0;
+
commit->object.flags &= ~mark;
parents = commit->parents;
while (parents) {
diff --git a/revision.c b/revision.c
index 993bb66..461ee06 100644
--- a/revision.c
+++ b/revision.c
@@ -1097,6 +1097,7 @@ static void rewrite_parents(struct rev_info *revs, struct commit *commit)
struct commit_list *parent = *pp;
if (rewrite_one(revs, &parent->item) < 0) {
*pp = parent->next;
+ commit->object.flags |= HALFORPHANED;
continue;
}
pp = &parent->next;
diff --git a/revision.h b/revision.h
index 3adab95..544238c 100644
--- a/revision.h
+++ b/revision.h
@@ -9,6 +9,7 @@
#define BOUNDARY (1u<<5)
#define BOUNDARY_SHOW (1u<<6)
#define ADDED (1u<<7) /* Parents already parsed and added? */
+#define HALFORPHANED (1u<<8) /* parents were rewritten */
struct rev_info;
struct log_info;
-- snap --
Note that this is just the idea. This particular implementation opens a
gaping memory leak, since the buffer of the commit is not free()d, and a
reparse would probably not pick up on the fact that the parent commits are
already in memory.
Ciao,
Dscho
^ permalink raw reply related
* Re: Commit f84871 breaks build on OS X
From: Brian Gernhardt @ 2006-12-07 16:04 UTC (permalink / raw)
To: Alex Riesen
On Dec 7, 2006, at 10:42 AM, Alex Riesen wrote:
> Does the attached patch help? I highly suspect the perl.mak generated
> by MakeMaker.
No, it doesn't. In fact, it looks like perl/Makefile is simply
getting overwritten by MakeMaker. I'm guessing MakeMaker is supposed
to be outputting to "perl.mak" instead?
perl version: 5.8.6 (from perl -v)
MakeMaker version: 6.18 (from /System/Library/Perl/5.8.6/ExtUtils/
MakeMaker.pm)
^ permalink raw reply
* Re: shallow clones, was Re: What's cooking in git.git (topics)
From: Alexandre Julliard @ 2006-12-07 16:44 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 <Johannes.Schindelin@gmx.de> writes:
> 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.
>
> So, do you actually know of people who _used_ (as opposed to "tested")
> shallow clones?
No, I'm afraid not. Unfortunately, using it requires an upgraded
server, and I'm reluctant to put an experimental release on the main
Wine server, so I was kind of waiting for it to graduate to master. Of
course that's a bit of a chicken and egg problem...
--
Alexandre Julliard
^ permalink raw reply
* Re: [PATCH] Documentation: reorganize cvs-migration.txt
From: J. Bruce Fields @ 2006-12-07 17:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612071522080.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Dec 07, 2006 at 03:28:33PM +0100, Johannes Schindelin wrote:
> This is a laudable goal, and the order makes sense (put first that what
> most people are interested in).
>
> A few comments:
Thanks for the comments! Patch, incremental against the previous one,
appended.
> - just skimming the patch, I found "commiting" (needs another "t"), and
> "-bare" (needs another "-").
Got it, thanks.
> - It might make more sense to "git init-db --shared" and fetch the initial
> revision into it, rather than clone it and then fix.
I do like the idea of anything that gets rid of the ugly find|xargs
chmod. Result included below (untested). Is that what you were
thinking of?
> You might also want
> to mention that the "--shared" of -clone is different in meaning from
> that of -init-db (make just a footnote of it, to avoid intimidating
> readers).
I'm ignoring this for now. We can add it later if someone says they've
run into it. (But honestly it's partly just laziness on my part--no
objection if you want to make the patch.)
It's too bad about that option-name conflict. It'd be nice just to be
able to do the whole thing with one clone commandline. And it'd also
make sense to allow clone and init-db to share commandline options where
it made sense.
> - By far the easiest method to import from cvs is to go to a checked out
> _CVS_ working directory, and just say "git cvsimport".
Neat, I didn't know about that. Done. I left the "-C" in there on the
assumption they often won't want to drop the result into the CVS working
directory.
Also did some miscellaneous cleanup.
--b.
commit 48ec79a74d0daa134b677ed5458beb873aa06e9a
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Thu Dec 7 12:38:09 2006 -0500
Documentation: simpler shared repo creation, miscellaneous cleanup
Create the shared repo with init-db --shared, fetch, and manual extraction
of .git directory, instead of using clone --bare.
Suggest running git-cvsimport from cvs working directory, more convenient
thatn providing all the CVS information on the commandline.
Fix a couple mispellings, add a couple manpage links.
Thanks to Johannes Schindelin.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 773fc99..4fab0d7 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -43,8 +43,8 @@ Pull: refs/heads/master:refs/remotes/origin/master
------------
================================
-You can update the shared repository with your changes by first commiting
-your changes, and then using:
+You can update the shared repository with your changes by first committing
+your changes, and then using the gitlink:git-push[1] command:
------------------------------------------------
$ git push origin master
@@ -76,11 +76,23 @@ possibly created from scratch or from a tarball (see the
link:tutorial.html[tutorial]), or imported from an already existing CVS
repository (see the next section).
-If your project's working directory is /home/alice/myproject, you can
-create a shared repository at /pub/repo.git with:
+Assume your existing repo is at /home/alice/myproject. Create a temporary
+empty shared repository and fetch your project into it:
------------------------------------------------
-$ git clone -bare /home/alice/myproject /pub/repo.git
+$ mkdir /pub/temporary
+$ cd /pub/temporary
+$ git init-db --shared
+$ git fetch /home/alice/myproject master:master
+------------------------------------------------
+
+Then create a "bare" repository at /pub/repo.git by just moving the contents of
+the .git directory there. The temporary repository can then be discarded.
+
+------------------------------------------------
+$ mv .git /pub/repo.git
+$ cd ..
+$ rm -rf temporary
------------------------------------------------
Next, give every team member read/write access to this repository. One
@@ -107,15 +119,15 @@ Importing a CVS archive
First, install version 2.1 or higher of cvsps from
link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
-sure it is in your path. The magic command line is then
+sure it is in your path. Then cd to a checked out CVS working directory
+of the project you are interested in and run gitlink:git-cvsimport[1]:
-------------------------------------------
-$ git cvsimport -v -d <cvsroot> -C <destination> <module>
+$ git cvsimport -C <destination>
-------------------------------------------
This puts a git archive of the named CVS module in the directory
-<destination>, which will be created if necessary. The -v option makes
-the conversion script very chatty.
+<destination>, which will be created if necessary.
The import checks out from CVS every revision of every file. Reportedly
^ permalink raw reply related
* Re: [PATCH] Documentation: reorganize cvs-migration.txt
From: Johannes Schindelin @ 2006-12-07 17:50 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20061207174306.GC16858@fieldses.org>
Hi,
On Thu, 7 Dec 2006, J. Bruce Fields wrote:
> +$ mkdir /pub/temporary
> +$ cd /pub/temporary
> +$ git init-db --shared
> +$ git fetch /home/alice/myproject master:master
Even easier:
$ mkdir /pub/my-repo.git
$ cd /pub/my-repo.git
$ git --bare init-db --shared
$ git --bare fetch /home/alice/myproject master:master
(Totally untested, of course.)
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andy Parkins @ 2006-12-07 17:49 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612070035570.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Wednesday 2006, December 06 23:42, Johannes Schindelin wrote:
> > * js/shallow (Fri Nov 24 16:00:13 2006 +0100)
> >
> > Probably with a better documentation of its limitations and caveats,
> > this should be mergeable to 'master'.
>
> The more I see the missing reaction, the less sure I am this is a sensible
> thing to do.
Don't be too downhearted. I am certainly looking forward to using shallow
clones; but by their very nature they are going to be used on big established
projects (otherwise why would one need a shallow clone?), so until those
projects upgrade their servers the news will be quiet
Also; it's probably going to be casual developers that find shallow clones
useful, as the main developers will clone the whole repository. This might
also mean that they aren't going to be around on the git mailing list.
I certainly wouldn't say that the shallow clone work is not being appreciated.
It's just being appreciated quietly.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: git pull and merging.
From: Junio C Hamano @ 2006-12-07 19:06 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <200612071227.46194.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> 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?
I accepted the "branch.*.merge" patch long time ago but I did
not see the point of moving things into config back then, so I
did not look at the design issue deeply enough to notice that
this can be a source of confusion (in other words, "I wouldn't
use it myself, but I've seen some people on the list wanting to
have it, and the submitter must have thought about what are
needed a lot more than myself" did not go so well).
Once you place something like "branch.*.merge" in configuration
file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you
are talking about other repositories you regularly interact
with, so it might be probably Ok to require the user to use a
tracking branch if he wants the convenience of "branch.*.merge",
and make its value name the local tracking branch instead of the
remote branch.
But that means I would never be able to benefit from the
convenience of "branch.*.merge"; I pull from gitk repository to
get updates, but I do not have (and I do not see the point to
have) a remote tracking branch to track it. If you want to
cater to people who fetch and merge without using tracking
branches, the remote branch name is the only sane thing you can
use for the value of "branch.*.merge".
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Linus Torvalds @ 2006-12-07 19:05 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Kernel Org Admin, Git Mailing List, Jakub Narebski
In-Reply-To: <45785697.1060001@zytor.com>
On Thu, 7 Dec 2006, H. Peter Anvin wrote:
>
> That all being said, the lack of intrinsic caching in gitweb continues to be a
> major problem for us. Under high load, it makes all the problems worse.
I really don't see what gitweb could do that would be somehow better than
apache doing the caching in front of it.. Is there some apache reason why
that isn't sufficient (ie limitations on its cache size or timeouts?)
Maybe the cacheability hints from gitweb could be tweaked (a lot of it
should be "infinitely cacheable", but the stuff that depends on refs and
thus can change, could be set to some fixed host-wide value - preferably
some that depends on how old the ref is).
Having gitweb be potentially up to an hour out of date is better than
causing mirroring problems due to excessive load.
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.
- 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.
- infinite for stuff that isn't ref-related.
Hmm?
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Junio C Hamano @ 2006-12-07 19:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0612070627r3ff0b394s124d95fbf8084f16@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> I have a kind of awkward project to work with (~44k files, many binaries).
>
> The normal "git commit", which seem to be more than enough
> for anything and anyone else, is a really annoying procedure
> in my context. It spend too much time refreshing index and
> generating list of the files for the commit message.
>
> At first I stopped using git commit -a (doing only update-index),
I am not sure what you are trying. Do you mean stat() is slow
on your filesystem?
> Is there any simple way to modify git commit for such a workflow?
> Failing that, any simple and _fast_ way to find out if the index
> is any different from HEAD? (so that I don't produce empty commits).
Maybe you want "assume unchanged"?
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-07 19:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Org Admin, Git Mailing List, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612071052560.3615@woody.osdl.org>
Linus Torvalds wrote:
>
> On Thu, 7 Dec 2006, H. Peter Anvin wrote:
>> That all being said, the lack of intrinsic caching in gitweb continues to be a
>> major problem for us. Under high load, it makes all the problems worse.
>
> I really don't see what gitweb could do that would be somehow better than
> apache doing the caching in front of it.. Is there some apache reason why
> that isn't sufficient (ie limitations on its cache size or timeouts?)
>
What it could do better is it could prevent multiple identical queries
from being launched in parallel. That's the real problem we see; under
high load, Apache times out so the git query never gets into the cache;
but in the meantime, the common queries might easily have been launched
20 times in parallel. Unfortunately, the most common queries are also
extremely expensive.
^ permalink raw reply
* Re: Locked down (but still shared) repositories
From: Shawn Pearce @ 2006-12-07 19:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612071640160.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 7 Dec 2006, Shawn Pearce wrote:
>
> > For various auditing reasons the repositories need to be tightly
> > controlled. That is the following cannot be permitted:
> >
> > [...]
>
> How about just one such user? After all, you already have this user: the
> repo owner. Of course, people have to push via ssh, even on the same
> machine.
How do I know which SSH key the client used to connect? Remember I'm
looking at the real uid to determine who is performing the operation.
In the situation you describe everyone looks the same to the
update hook...
For (probably stupid) reasons the server is the commerial F-Secure
SSH server, btw. So OpenSSH based things wouldn't apply. And best
that I can tell, F-Secure SSH won't tell me which key was used
to authenticate.
--
^ permalink raw reply
* Re: [PATCH] Add config example with respect to branch
From: Junio C Hamano @ 2006-12-07 19:20 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <4577B687.5080907@gmail.com>
I've tolerated patches in attachments, but please do not do
this:
This is a multi-part message in MIME format.
--------------010006030902030700040300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
--------------010006030902030700040300
Content-Type: text/plain;
name="0001-Add-config-example-with-respect-to-branch.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="0001-Add-config-example-with-respect-to-branch.txt"
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Update config.txt with example with respect to branch
config variable. This give a better idea regarding
how branch names are expected.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
Documentation/config.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
Instead have the proposed commit log message (and From: line if
you are forwarding somebody else's patch, or if your MUA does
not record your own name correctly) in the first part (which is
empty in your message).
^ permalink raw reply
* Re: Bug in merge-recursive in virtual commit corner case
From: Shawn Pearce @ 2006-12-07 19:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612071636030.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 7 Dec 2006, Shawn Pearce wrote:
>
> > So I managed to create a fairly complex set of branches which are all
> > merged back against each other at various points in time. Two of
> > them have 3 merge bases according to git-merge-base. Tonight I
> > tried to merge them together, but received the following wonderful
> > error from git-merge-recursive:
> >
> > fatal: unable to read source tree (4b825dc642cb6eb9a060e54bf8d69288fbee4904)
> >
> > For those in the know, that's the empty tree. This particular
> > repository does not have the empty tree anywhere in it, which is why we
> > can't read the object: it doesn't exist, and shouldn't exist.
>
> I think there is something else wrong. If you have three merge bases, I do
> not see how you could get into that particular code path.
Arrgh. I can redo the merge and try to debug it myself; maybe I
can at least get enough details about what's going on to create a
dummy repo which exhibits the same behavior.
> Any possibility for me to have a private look at your repo?
No, unfortunately for me (I wish I could let you debug this!).
Far too many legal issues are involved. There is possible jail
time on my part for sharing any of the files in there... ;-)
Although Junio mentioned he recently saw something like this in
git.git when he merged in your xdl_merge() code. I wonder if its
the same issue.
--
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Shawn Pearce @ 2006-12-07 19:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vd56vtt2g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > I have a kind of awkward project to work with (~44k files, many binaries).
> >
> > The normal "git commit", which seem to be more than enough
> > for anything and anyone else, is a really annoying procedure
> > in my context. It spend too much time refreshing index and
> > generating list of the files for the commit message.
> >
> > At first I stopped using git commit -a (doing only update-index),
>
> I am not sure what you are trying. Do you mean stat() is slow
> on your filesystem?
Its Cygwin/NTFS. lstat() is slow. readdir() is slow. I have the
same problem on my Cygwin systems.
> > Is there any simple way to modify git commit for such a workflow?
> > Failing that, any simple and _fast_ way to find out if the index
> > is any different from HEAD? (so that I don't produce empty commits).
>
> Maybe you want "assume unchanged"?
Yes, basically. The Cygwin/NTFS issues Alex is pointing out are
exactly why git-gui has a "Trust File Modification Timestamp" option
on both a per-repository and global level. My larger repositories
(~10k files) are difficult to work with without that option enabled.
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Olivier Galibert @ 2006-12-07 19:30 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <457868AA.2030605@zytor.com>
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.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Linus Torvalds @ 2006-12-07 19:30 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Kernel Org Admin, Git Mailing List, Jakub Narebski
In-Reply-To: <457868AA.2030605@zytor.com>
On Thu, 7 Dec 2006, H. Peter Anvin wrote:
>
> What it could do better is it could prevent multiple identical queries from
> being launched in parallel. That's the real problem we see; under high load,
> Apache times out so the git query never gets into the cache; but in the
> meantime, the common queries might easily have been launched 20 times in
> parallel. Unfortunately, the most common queries are also extremely
> expensive.
Ahh. I'd have expected that apache itself had some serialization facility,
that would kind of go hand-in-hand with any caching.
It really would make more sense to have anything that does caching
serialize the address that gets cached (think "page cache" layer in the
kernel: the _cache_ is also the serialization point, and is what
guarantees that we don't do stupid multiple reads to the same address).
I'm surprised that Apache can't do that. Or maybe it can, and it just
needs some configuration entry? I don't know apache.. I realize that
because Apache doesn't know before-hand whether something is cacheable or
not, it must probably _default_ to running the CGI scripts to the same
address in parallel, but it would be stupid to not have the option to
serialize.
That said, from some of the other horrors I've heard about, "stupid" may
be just scratching at the surface.
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Shawn Pearce @ 2006-12-07 19:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <20061207192632.GC12143@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Its Cygwin/NTFS. lstat() is slow. readdir() is slow. I have the
> same problem on my Cygwin systems.
Just to be clear, I'm not trying to blame Cygwin here.
Windows' dir command is slow. Windows Explorer is slow while
browsing directories. Eclipse chugs hard while doing any directory
scans (it normally runs very fast if its not rescanning the entire
directory structure). The drive is just plain slow.
Yea, I know, get a faster disk... but some bean counters don't
believe that a $50 more expensive disk could ever save enough time
to warrant the extra $50 captial expenditure...
I spend at least an hour a week waiting for enough IO to finish so
that the mouse pointer will move again. *sigh*
--
^ permalink raw reply
* Re: [PATCH 2/2] Optionally check for uncommitted changes before switching branches.
From: Junio C Hamano @ 2006-12-07 19:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061207100224.GB12966@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Git shouldn't cause the user to make mistakes when it can help to
> prevent them. So now users may set checkout.requireCleanDirectory
> to true in their config file to have git-checkout verify the working
> directory is clean before switching branches.
A lot of times the reason to switch branches is because the user
starts to make a trivial change in the worktree and realizes
that the change belongs to another branch. Other times it is
done by mistake and making it easier to notice that mistake is a
laudable goal.
Your patch allows -m to override this, but that destroys one
very useful feature of -m. In the above "ah, this trivial thing
belongs to the other branch, so let's switch to the branch to
commit only that trivial piece and come back to the current
branch to continue what I'm doing" workflow, I usually first say
"git checkout" without -m to switch, and if it does not allow me
to switch, it is an indication that "the trivial thing" I
thought was trivial was not trivial. I take it as a cue that I
should instead do it "the right way" (i.e. finish or stash away
what I am doing, switch to the branch in a clean state and fix
it properly).
Other times, when all (or most of) the changes in the work tree
logically should have started on a different branch, I do force
it with -m (and take the conflict markers in my worktree), but
being able to forbid the worktree merge by not giving -m is
important.
People with this new configuration set and has to override it
with a command line switch will lose this ability if you
overload that on '-m'.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Shawn Pearce @ 2006-12-07 19:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612071121410.3615@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> I'm surprised that Apache can't do that. Or maybe it can, and it just
> needs some configuration entry? I don't know apache.. I realize that
> because Apache doesn't know before-hand whether something is cacheable or
> not, it must probably _default_ to running the CGI scripts to the same
> address in parallel, but it would be stupid to not have the option to
> serialize.
AFAIK it doesn't have such an option, for basically the reason
you describe. I worked on a project which had much more difficult
to answer queries than gitweb and were also very popular. Yes,
the system died under any load, no matter how much money was thrown
at it. :-)
> That said, from some of the other horrors I've heard about, "stupid" may
> be just scratching at the surface.
It is. :-)
--
^ 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