This conflicted in a funny way with your own commit but I think this version (773fc99 blob) supersedes its contents. I munged only one line, though. The title of this section should not be "a CVS repository" but "a shared repository" for -

So the library approach sounds like the best? Of course in this case the producer git-rev-list and the receiver use the same address space. In the case of a temporary file data is first copied to OS disk cache buffers and then again to userspace, in qgit address space. But the real pain is that the temporary file is always flushed to disk after 4-5 seconds from creation, also if under heavy read/write activity. This is a problem for big repos. I really don't know how to workaround this useless...

I liked this. This avoid lot of confusion and the "magic" master update. -aneesh -

I started that out at 5000 because it was a reasonably safe threshold. Users who didn't explicitly lower this value didn't enable the feature. But it was still useful on initial pushes into a brand new repository when the project was very large. For example pushing git.git into a bare repository *sucked* before this change. Yea, 5000 is probably too high. Nice to see it drop. -- Shawn. -

It wasn't so much the what's current - as you say that would be fairly ridiculous as it's so fluid. It was more a description of the topic. I've got tonnes of branches where I have quickly thought of an idea and started work on it, only to get bored and move on. Describing a topic in such a short space as "ap/short-name" is hard. The actual place it's stored isn't really relevant, more that I could see a use for it. If it's going in the config I suppose all it needs is a magic "and so i...

I hit the same issue when I integrated Johannes's in-core merge; I originally used hash_sha1_file() but that results in objects that are supposed to be in the virtual parent unreadable when merging the real children. The key is to use write_sha1_file() to actually create the needed objects, and trust later prune to remove them. Replace it with write_sha1_file() and you should be fine, I think. -

I have recently observed a rather large number of users who forget to specify the base revision when they start a new branch with git-checkout -b. Many of these users are shocked many hours and commits later when their prior branch is now also part of the new branch. Nasty words about Git usually follow the discovery. This introduces a new config option: checkout.requireSourceBranch, which the user can set to make git-checkout -b require them to supply not only the new branch name but also the in...

There are some baseless merge cases where git-merge-recursive will try to compare one of the branches against the empty tree. However most projects won't have the empty tree object in their object database as Git does not normally create empty tree objects. If the empty tree object is missing then the merge process will die, as it cannot load the object from the database. The error message may make the user think that their database is corrupt when its actually not. So instead we should just cre...

No. The merging part actually is the easiest, because everything about what to merge with what is already decided in "git pull" 's fetch phase: * git fetch leaves the branches fetched _and_ what to merge of them in .git/FETCH_HEAD. Example for "git pull" it git.git's master(shorted): de51fa... branch 'master' of git://.../git/git 49ed2b... not-for-merge branch 'maint' of git://.../git/git b772ef... not-for-merge branch 'next' of git://.../git/git Which means: Already in the fetch phase,...

scratch this. I just noticed I had somehow managed to get the directory setup like this: devel:softpub/mkpub.git <-- a real repo devel:softpub/mkpub.git/.git <-- the repo that got pushed to -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -

One's gotta wonder how that's ever a valid directory setup... Although I'm running a configuration of: root/proj.git <-- a real repo root/proj.git/info/new-commit-check <-- a fake repo where new-commit-check has root/proj.git not only as an alternate ODB but also has root/proj.git/refs symlinked into its own refs directory. -- Shawn. -

hoi :) perhaps don't refuse to run, but simply change back to the safed uid? Or use one special machine which hosts the repository and which has the modified version of git installed. --=20 Martin Waitz

e.g. http://svn.berlios.de/viewcvs/open-iscsi/ http://svn.berlios.de/svnroot/repos/open-iscsi Can I convert / to master simply ? Thanks -

When I pulled the most recent changes for git (de51faf), `make` began failing with the following messages: make -C perl PERL_PATH='/usr/bin/perl' prefix='/usr/local/stow/git' all Makefile out-of-date with respect to Makefile.PL /System/Library/Perl/ 5.8.6/darwin-thread-multi-2level/Config.pm /System/Library/Perl/5.8.6/ darwin-thread-multi-2level/CORE/config.h Cleaning current config before rebuilding Makefile... mv: rename perl.mak to perl.mak.old: No such file or directory make[1]: *** [perl....

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), now I'm about to start using write-tree/commit-tree/update-ref directly. It helps, but sometimes I really miss -F/-C. It's also ...

Strange. You seem to have the old, generated Makefile you perl/ directory. Haven't your pull failed? If so, I suspect that rm perl/Makefile git reset --hard git pull git... should fix it. -

We could setup the branch.*.remote option for every tracking branch git-clone is fetching (and git-fetch with the wildcard refspec). And git-branch sets branch.*.remote/merge for the new branch whenever it sees that a remote is set for the branch we are I see. But I hope with my suggestion above, this can be looked up then in the branch."remotes/origin/for-public".remote option. Josef -

Hi, I found the same, but could not reproduce it. But a "touch perl/perl.mak" fixes at least compilation. Ciao, Dscho -

I've found the same problem as the OP. First my pull failed like you said, but then I completely wiped my working copy and tried checkout again -- this time it worked fine. However, the build still fails with the error mentioned by the OP. -- Pazu -

I had to do the same. Somewhere, there's a "mv" that tries to move perl.mak out of the way and doesn't properly detect the fact that it isn't there. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -

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

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

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

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) ~~ Brian -

Thanks for the comments! Patch, incremental against the previous one, 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 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 c...