Hi, I'm attempting to convert a fairly large SVN repository to git (about 60000 revisions, quite a few branches and tags). It looks like git-svn is the main tool for this purpose but it is very slow. The initial fetch takes many hours to finish (yes, I'm working locally) and seems to periodically die after a few thousand revisions. Is git-svn really the best tool? Ideally I would like to feed an svn dump into some tool and end up with a git repository. If I would feed incremental dumps into ...

How about an extra option to explicitly toggle the separator on or off? For example, how about "--sep=<count>"? Using --sep=0 would put no separator between entries. --sep=N would put N separators between entries. If this option isn't explicitly specified, the default should be --sep=0 for ONELINE, and --sep=1 for everything else. Using --sep=2 with USERFORMAT would achieve the behavior of getting an extra line of padding between entries. This still leaves unresolved the fact that ...

With this patch, "git log --decorate --pretty=format:%d", shows the name decoration (i.e. whenever a commit matches a ref, that ref's name is shown). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- Maybe %d should expand to " (<name decoration>)" instead of "<name decoration>"? Documentation/pretty-formats.txt | 1 + pretty.c | 9 +++++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/Documentation/p...

A set of big questions is how that git.webvm.net/srv/git/webkit-test repository was prepared, what its history look like and how it relates to the history your repository has. I presume that that is different from the repository you are pushing from (which is "x61:aplix/test/WebKit" repository), but other than that you did not give any details to guess By the way, that --thin is an implementation detail and not meant for the end user consumption. I do not think it would matter in this case, W...

That explains it without the "theory" in my previous message. The destination repository must be populated with full history somehow (and one way would have been to start it by cloning from the upstream), but if it was empty that is alright as well, because your push made it up-to-date. IOW, there is nothing to worry about and the system is working as designed. Further pushes will update it incrementally. --

I've recently started to notice the following being reported: % git-status error: bad index file sha1 signature fatal: index file corrupt (a) Is there anything I can do to fix this (apart from git-clone from the repo and start over) ? git-fsck reports the same problem. (b) What is causing it? Is it just my hard disk failing, or is it a bug? A memory test seems to be OK. Linux 2.6.22-3-amd64 File system is XFS git version 1.5.4.4 --

--

This behavior should be a lot better for recent kernels. xfs does even better with write barriers. But any file change that is more than one write can be corrupted or split by an inopportune powerdown. David --

This change automatically enables parent rewriting when --graph is specified. This makes the graph output look much nicer when commit pruning is enabled. The existing rev_info "parents" flag has been split into two flags: "rewrite_parents" causes the parents to be rewritten, while "print_parents" causes the log and rev-list commands to print the parents. The --parents option now enables both rewrite_parents and print_parents, while --graph enables only rewrite_parents. Signed-off-by: Adam Simp...

The above also applies to Finnish and Norwegian keyboards, probably to many more. The key pair '=' and '-' would be a poor UI decision. In principle one should never assume that a key is in certain place in the keyboard; it's much better idea to be logical with _characters_. So if a key pair much be defined for different aspects of the same functionality, let's choose logical pairs from common characters: +- [] {} () <> zZ aA bB ... (To me all these are OK.) --

Well, it does fix the stgit test suite failure, so I'm all for it! (Though I see you've already pushed it to master.) Thanks. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle --

Well, I just rebased my entire tree, and then plopped your four patches (these three plus 009f) on top of it. So no need to rebase. Its better. I'd like to be able to use more of RevFilter in the search, but as you pointed out support isn't all there yet. I'm taking in this series as is. We can improve on it further later. Thanks. -- Shawn. --

The current practice is we expect .c files to include necessary .h files themselves and avoid including .h files from others (I do not personally necessarily agree with this practice, by the way, but that is the way it We seem to consistently use postfix when increment is done only for its side effect. --

Hmm. This is a harder problem to fix. All of the options you list above are handled by the internal diff API. The diff API doesn't have any knowledge about log and rev-list options, such as --graph. The nicest way to fix this would probably be to write new diff API functions that output to a strbuf instead of printing directly to stdout. Then the log code could prefix each line of the buffer with the graph info before printing it. However, this would be a lot of work, and I'm not sure that ...

As I've spent some time in testing the --graph functionality I'm spamming my discoveries here. When limiting the log output to a subdirectory or to a file the graph becomes quite hard to understand. Probably the easiest way to demonstrate my point is to compare side by side (for example) git log --graph --pretty=oneline -- Documentation/ and gitk -- Documentation/ in the Git repository. gitk draws lines between commits even when they are not in direct parent-child relationship (i.e...

Signed-off-by: Teemu Likonen <tlikonen@iki.fi> --- Hmm, why not add some more useful long options? There are plenty of them of course but I feel these are one of the most common. contrib/completion/git-completion.bash | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 4d81963..02a5fd3 100755 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.ba...

Previously, the --graph option had problems when used together with --pretty=format. The output was missing a newline at the end of each entry, before the next graph line. This change updates the code to treat CMIT_FMT_USERFORMAT just like CMIT_FMT_ONELINE, even when --graph is not in use. Like CMIT_FMT_ONELINE, the pretty_print_commit() output for CMIT_FMT_USERFORMAT lacks a terminating newline. Similarly, there should be no blank line between entries for CMIT_FMT_USERFORMAT. The old code to...

Some alternatives to specify terminator semantics I considered are: (1) Presence of %_ in "--pretty=format:..." triggers terminator semantics and %_ itself interpolates an empty string; otherwise separator semantics is used. (2) Presence of %n in "--pretty=format:..." means a multi-line output and uses separator as before; lack of %n means it is a one-line format and uses terminator. (3) A new option --pretty=tformat:... (i.e. tformat instead of format) means LF (...

How about: (5) There is no automagic terminator or separator for user formats. %n translates to a newline. %N translates to a newline, unless this is the final record, in which case it translates to the empty string. So: # oneline git log --pretty=format:'%h %s%n' # multiline git log --pretty=format:'%h%nSubject: %s%n%N' The main drawback is that dropping the automatic separator breaks existing uses. We could work around this by automatically appending ...

Well, in your example, the large image part should already be common to many objects due to deltas if they're really the same: different objects will only have different EXIF data plus a delta reference to the same base image object. So in a way the split is already there. Needs only that some applications exploit this information at runtime. Nicolas --

In practice I don't know how well that would work since the current heuristic groups deltas and their base according to the name under which those objects are known. So it is possible that some inexact renames end up creating objects that currently never delta against each other even if that would be the right thing to do. But in some cases, that might be beneficial to look at the delta object themselves when diffing files as the delta might already contain the information telling the up...

More or less, yes. It gets worse if a user does 'cvs update' in a It's not 'my framing of the problem.' It's 'the design goal of cvsps is not compatible with the desire to use the output of cvsps to create a Yes. That's what cvs2git was designed for. Look at the name. In order to create the 'fixup' branch, you have to make some out of operations, which is fine if that's what your design goal is. The design goal of cvsps was always simply to show who did what and in what chronological o...

I've known of this bug for a while but didn't track it down until now. Please let me know if this fixes things for you and if there are any regressions; thanks. From a9ebe54adf7ae2620fba1f638dee9566f8ccca82 Mon Sep 17 00:00:00 2001 From: Eric Wong <normalperson@yhbt.net> Date: Mon, 7 Apr 2008 00:41:44 -0700 Subject: [PATCH] git-svn: fix cloning of HTTP URLs with '+' in their path With this, git svn clone -s http://svn.gnome.org/svn/gtk+ is successful. Also modified the funky rename t...

Hi Tim, the HTTP repository should be fixed with the patch in http://article.gmane.org/gmane.comp.version-control.git/78961 -- Eric Wong --