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

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... -- Alexandre Julliard julliard@winehq.org -

Having for a long time been thoroughly annoyed by our strict umasks, I decided to write a little program to deal with it, and naturally I put it in a git repo. After the initial commit (c0fa1db09bad112f7271378d907bf33d74c06f6b) I published it to my git space on our development server and cloned it out again (to get the nifty remotes things set up for free). Then I noticed I had rushed it, as I usually do with hacks involving a total of less than 200 lines of code, so I had to make a couple of...

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 -

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

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

[Empty message]

This is most confusing part. What merge indicate is not about refs/heads/devel should track refs/remotes/origin/devel. That is specfied in the remote config option. What merge indicate is that when in a local branch ( not the tracking one under remotes/origin) I guess we need to have a standard way of saying the branches. May be we want to document it in repo-config. local branch on which changes can be made <branch-name> local tracking branch refs/remotes/<remote-name&...

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

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

With the appreciation of your friendship our Group would like to represent a new special offer created for all the customers who prefer to use our services. Needless to say that we're trying to help you with your choices, because we offer a quality software at lowest prices on the web. Make your choice, don't miss a chance. We're always at your service. The following special offer will operate within next 7 days only http://gigazoyd.com Every effort has been made to ensure the accuracy of all information ...

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

git svn init http://svn.berlios.de/svnroot/repos/open-iscsi git svn fetch -- Eric Wong -

That's correct. I can transfer that directory to you if you want; I can't realistically track gitweb well enough to do this myself (in fact, it was pretty much a condition of having it up there that Kay would keep How do you want to handle it? -hpa -

The front page, summary page of each project, and the RSS feed for each project. -hpa -

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

Oops, yes, thanks! --b. -

Well, it's true that "git branch" is the first thing I type whenever I sit down, just to remember where I am.... But my main complaint is just that I wouldn't want to see the behavior of defaulting to HEAD--behavior which is simple, easy to explain, and shared by most other git commands--by something significantly more complicated. That's more a complaint about Junio's suggestion than yours, though. --b. -

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, can you send me at least the output of $ git-rev-list --parents branch1 branch2 preferrably packed? There is nothing you can do legally wrong, since you are not sending any data, only metadata. Ciao, Dscho -

Hi, This is a laudable goal, and the order makes sense (put first that what most people are interested in). A few comments: - just skimming the patch, I found "commiting" (needs another "t"), and "-bare" (needs another "-"). - It might make more sense to "git init-db --shared" and fetch the initial revision into it, rather than clone it and then fix. You might also want to mention that the "--shared" of -clone is different in meaning from that of -init-db (make just a footnote...

Hi, 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? Ciao, Dscho -

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

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 -