At some point between v5.6 and 5.8 Perl started to assume its input, output and filehandles are UTF-8. This breaks the counting of bytes for the CVS protocol, resulting in the client expecting less data than we actually send, and storing truncated files. Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> --- This has gone unfixed for quite a while. I thought I had seen a patch posted addressing it, but it may have been for something else. In fact, our heavily patched gitweb.cgi has ...

I think the right place to store that <anything at all> information is per-branch configuration item. Perhaps: [branch "ap/clone-origin"] description = we talk about what this thing does and \ what the current status of it is. I am unlikely to use such a thing for the "What's in" message, though. The part that talks about "what the current status is" is much easier to write when I need to talk about "the current"; otherwise I'd be forced to remember to think if I need ...

This only makes "update; edit; update; commit" to work. "edit; commit; edit; commit; edit; update; commit" would not work, because you would be faced to resolving the conflicts upon the last update while your working tree is already contaminated with your own changes (it can be done and experienced people have done so, but you are talking about "CVS users" here). We'd be much better off to encourage users to shake "update then Then test it and fix breakage if any please. -

I want to grab a single file from a remote git repository into the current directory, which is not a git tree. Is there an easy way to do that? I have tried using git-fetch and git-cat-file, without success. Thanks, Mitch Bradley -

Here is a list of topics that are cooking; the commits marked with '+' are in 'next', '-' are in 'pu'. Dates are when the topic was last touched [*1*]. ---------------------------------------------------------------- * ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000) + Explicitly add the default "git pull" behaviour to .git/config on clone This makes 'git clone' to mark the local 'master' to explicitly merge with the corresponding remote branch, which would be a sensible default. As di...

* The 'maint' branch has produced a new release 1.4.4.2 * In the 'master' branch: - we now officially favor 'remotes' information to be in $GIT_DIR/config, and 'git clone' records origin in there, not in $GIT_DIR/remotes/origin (thanks to Andy Parkins). - "git send-pack $URL :refs/heads/$branch" can be used to delete a remote branch (so does "git push $URL :$ref" over git native protocols). - built-in shortlog lets you directly say "git shortlog v2.6.18..master", i...

Currently the treshold is 5000. The likelihood of this value to ever be crossed for a single push is really small making it not really useful. The optimal treshold for a pure space saving on a filesystem with 4kb blocks is 3. However this is likely to create many small packs concentrating a large number of files in a single directory compared to the same objects which are spread over 256 directories when loose. This means we would need 512 objects per pack on average to approximagte the sa...

Note that this setting is currently observed for pushes not pulls. On the pull side you currentli need to provide -k for not exploding packs. So the question is what number of objects on average do pushes have? If most pushes are below the treshold this is not going to be really useful. And I think 5000 is definitely way too high. 10 might be too small indeed. 100 is maybe a good default to try out. Nicolas -

I see you are optimizing for disk footprint, and this will result in tons of tiny packs left between "repack -a". I have not benched it yet, but the runtime pack handling code was written assuming we have only a handful of big packs; I suspect this change would affect the performance at runtime in quite a bad way. -

I ask help to the list because my knowledge on this is not enough. Currently qgit uses, socket based, QProcess class to read data from 'git rev-list' when loading the repository at startup. The time it takes to read, without processing, the whole Linux tree with this approach it's almost _double_ of the time it takes 'git rev-list' to write to a file: $git rev-list --header --boundary --parents --topo-order HEAD >> tmp.txt We are talking of about 7s against less then 4s, on my box (war...

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

Where can I found some documentation (yes I know RTFS, but...) or, better, an example of using the API to read git-rev-list output? if it is possible I also would like to avoid to mess with internal git API's, of course *if it is possible* ;-) Thanks Marco -

You'll also need to call: setup_git_directory(); Although now that I think about it the library may not be enough of a library. Some data (e.g. commits) will stay in memory forever once loaded. Pack files won't be released once read; a pack recently made available while the application is running may not get noticed. 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 seein...

On a modern Linux (probably your largest target audience) a small file which has a very short lifespan (few seconds) is unlikey to hit the platter. Most filesystems will put the data into buffer cache and delay writing to disk because temporary files are so common on UNIX. And ugly. :-) SysV IPC (shared memory, semaphores) are messy and difficult to get right. mmap against a random file in the filesystem tends to work better on those systems which support it well, provided that the file ...

Thanks for the comments you made here---that's the kind of thing I was looking for. As for where I'm trying to lead us, what I really want to do is to help improve the learnability of git. A big part of that is about improving the set of "use-oriented" documentation, (which describes how to achieve tasks, as opposed to what might be termed "technically oriented" documentation which describes how individual tools work). I think too much of the existing documentation falls into the second class. ...

Why? URL: some-where Pull: refs/heads/master:refs/remotes/origin/master Pull: refs/heads/*:refs/remotes/origin/* works just fine. But we should encourage people to use config to define default merge source per-branch. -

I wouldn't go that far, as it would forbit perfectly good "git fetch" from anywhere in the sources meaning "git fetch origin". -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Hi, Not to talk about portable, and as we saw, dependent on the C compiler (you would have to make git compile with the same C compiler that perl was compiled with). So, please look into other options first. Ciao, Dscho -

Am Mittwoch, den 06.12.2006, 17:58 +0100 schrieb Jakub Narebski: I had the same idea after the sed problems with macos/solaris, but embedded perl is really a bit horrible. Then we could just use (.*) and \1..9 and use extended REs. The only problem is this stupid sed thing, only GNU-sed has the -r I would prefer the following ways to do this globfetch stuff: 1.) The original refspec: Pull: refs/heads/master:refs/remotes/origin/master 2.) The one with "prefix match": Pull: refs/heads/:...

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://tarantullbabe.net Every effort has been made to ensure the accuracy of all informa...

because a newbie doesn't know how to resolve that problem. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen -

Would it be hard to add "-p / --stdout" options, and "-q / --quiet" option? I understand that non-standard output format options are rather out of question... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

merge-file has the same syntax as RCS merge, but supports only the "-L" option. For good measure, a test is added, which is quite minimal, though. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> --- Is it a good sign that the test makes up for 75% of this patch? builtin-merge-file.c | 72 ++++++++++++++ builtin.h | 1 + git.c | 1 + t/t6023-merge-file.sh | 251 ++++++++++++++++--------------------------------- 4 files changed,...

When merging changes into a dirty working copy, one may get .. Updating 62a005d..7bbd698 Makefile: needs update README: needs update config.mak.in: needs update configure.ac: needs update fatal: Entry 'Makefile' not uptodate. Cannot merge. .. This is bad error message; "uptodate" suggests that Makefile is too old. The problem is the reverse. The Makefile has been edited and hence it is 'newer'. This message should say Entry 'Makefile' is dirty. Revert or commit changes bef...

Yes - I'd just mention revert as an option too. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen -