Having got a C implementation of fetch far enough to be able to tell me that I'm up-to-date (when using git:// and not using remotes or branches files) I thought I'd compare performance with the fetch--tool based version. I was a bit surprised at what I saw. Hot-cache time went from ~30s to ~3s, which didn't seem too bad. However what did puzzle me was where the C version was spending it's time. Being a work in progress it's a bit chatty in places, but there is an up-front delay of just ov...

From: J. Bruce Fields <bfields@citi.umich.edu> Manual clean-up of cross-references, and also clean up a few definitions (e.g. git-rebase). Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> --- Documentation/glossary.txt | 58 ++++++++++++++++++++++---------------------- 1 files changed, 29 insertions(+), 29 deletions(-) diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt index 82e17db..2465514 100644 --- a/Documentation/glossary.txt +++ b/Documentation...

Also available from: git://linux-nfs.org/~bfields/git.git The main change is just to maintain the glossary manually instead of by the sort_glossary.pl script; includes a subsequent patch to demonstrate the sort of cleanup that allows. --b. -

From: Jim Meyering <jim@meyering.net> "file patch" was doubtless intended to be "file path", but "directory name" is clearer. Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> --- Documentation/user-manual.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 0919574..773f65e 100644 --- a/Documentation/user-manual.txt +++ b/Docu...

From: J. Bruce Fields <bfields@citi.umich.edu> The sort_glossary.pl script sorts the glossary, checks for duplicates, and automatically adds cross-references. But it's not so hard to do all that by hand, and sometimes the automatic cross-references are a little wrong; so let's run the script one last time and check in its output. Note: to make the output fit better into the user manual I also deleted the acknowledgements at the end, which was maybe a little rude; feel free to object and ...

Compare didn't work at the project level when the project wasn't the same as the git working directory, i.e. egit itself. Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> --- .../core/internal/mapping/GitFileRevision.java | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/internal/mapping/GitFileRevision.java b/org.spearce.egit.core/src/org/spearce/egit/core/internal/mapping/GitFileRevision.java ...

Hi, I have to disagree. Git is substantially more sane than CVS, so that it is actually _simpler_ to learn Git than to unlearn CVS and _then_ learn Git. Ciao, Dscho -

Well, experience may consist of few days playing with Git. But it is not what I wanted to say. I wanted to say that before doing any work on Git tests one should get to know what SCM is about. By the way, in "more extensive tests" did you want also tests of Git _API_, and not only git commands (porcelain and plumbing)? IIRC the "more tests" proposal for SoC2007 was by you... (And yes, I think that Git has most sane ideas about SCM). -- Jakub Narebski Poland -

Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> --- git-mergetool.sh | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/git-mergetool.sh b/git-mergetool.sh index 52386a5..563c5c0 100755 --- a/git-mergetool.sh +++ b/git-mergetool.sh @@ -185,9 +185,9 @@ merge_file () { mv -- "$BACKUP" "$path.orig" fi ;; - meld) + meld|vimdiff) touch "$BACKUP" - meld -- "$LOCAL" "$path" "$REMOTE" + $merge_tool -- "$LOCAL" "$path" "$REMOTE"...

This is mainly just a cleanup patch, and sets up for later changes where the tree-diff.c "interesting()" function can return more than just a yes/no value. In particular, it should be quite possible to say "no subsequent entries in this tree can possibly be interesting any more", and thus allow the callers to short-circuit the tree entirely. In fact, changing the callers to do so is trivial, and is really all this patch really does, because changing "interesting()" itself to say that not...

Thanks for this series. I have applied it and pushed it out, along with a small fix on top. It works nicely, at least the "NG" variant when comparing trees. ;-) The non-NG variant shows the raw tree diff, which is uh, a little uninteresting, unless you are a true core Git hacker... I tested it on a small-ish repository. The history browser works quite nicely once the cache starts to get filled. I don't know how well it works on bigger repositories. ;-) --'da small fix-- From 6c402714c...

We now use SoftRefernces to hold the value objects and reuse the object id's as cache keys. Seems to work much better, i.e. the gc only throws out stuff from the cache when memory is tight, rather than at the first opportunity. Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> --- .../src/org/spearce/jgit/lib/Repository.java | 30 +++++++++++++++-------- 1 files changed, 20 insertions(+), 10 deletions(-) diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository...

The caching part is experimental. We explicitly leave it up to the garbage collector when to recycle git objects. After trying this practically we will se what is best. The upside is that rescanning the history for a certain resource is very quick when data is still in the cache (tens of milliseconds), which is very good for interactivity. When memory is tight we go to disk and fetch the data, which could take a couple of seconds on a large repo. Signed-off-by: Robin Rosenberg <robin.rosenberg@...

This makes "track_tree_refs()" use the same "tree_entry()" function for counting the entries as it does for actually traversing them a few lines later. Not a biggie, but the reason I care was that this was the only user of "update_tree_entry()" that didn't actually *extract* the tree entry first. It doesn't matter as things stand now, but it meant that a separate test-patch I had that avoided a few more "strlen()" calls by just saving the entry length in the entry descriptor and using it d...

Maybe while waiting for application nor comments you could have tested and removed that comment? -

Hi, I have a repository with a working tree on a machine A, did a clone to another machine B and commited there locally. I want my changes to get back into the first repository, so I did a "push". The new commit is in the history, I can see it with "git log", but the modifications are not in the working tree. This time, it's OK: I didn't have any uncommited modifications on A, so I just did a "git reset --hard HEAD" there. But if I had some uncommited changes, "git reset --hard HEAD" means ...

Doesn't update hook get pre- and post- commit object name? -

In my comments, I was observing that *after* the push had succeeded, there was no way to find the commit-id-before-the-push, since neither the reflog nor ORIG_HEAD is getting updated. Is there a good reason why not? Would you accept a patch which caused the reflog and possibly ORIG_HEAD to be updated on the remote side of the push? When I was talking about a hook to enforce the BitKeeper semantics, the question is whether we have enough to enforce the following: * Only accept the push if i...

Ah, so that's controlled by receive.denyNonFastForwards, right? Cool, I missed that. Thanks!! Documentation/config.txt doesn't say it defaults to true, but from What git-runstatus will allow me to do is to abort if there are any local modifications, regardless of whether or not they would conflict with the working tree update. The key phrase in my criteria was no locally modified files "THAT WOULD BE AFFECTED". What I could do with BitKeeper is that I could modify some file like schedule....

So I dug a little more deeply, and the problem is that the reflog for master was getting updated, but not the reflog for HEAD, and that's what "git reflog" was showing --- hence my confusion. What are the rules for when HEAD's reflog should get updated, and is this documented anywhere in the man pages? - Ted Script started on Sun 18 Mar 2007 11:11:59 PM EDT Top-level shell (parent script) Using ssh-agent pid 7679 <tytso@candygram> {/home/tytso/talks/dscm/git} 1% cp -r test1 t...

Actually, there are no such "design choices". That's entirely up to the repository owners to arrange post-update hook, to allow you to do anything you want. The default is not to encourage people (who do not know what they are doing anyway) to push into non-bare repository. -

We talked about that in the past on the list. No. -

The problem description looks correct, but I think the original meant to reject configuration value for merge_tool that is not IOW, wouldn't this be a better way? if test -z "$merge_tool" then merge_tool=`git-config merge.tool` case "$merge_tool" in kdiff3 | tkdiff | xxdiff | meld | emerge) ;; # happy *) echo >&2 "We do not know how to drive $merge_tool" ...

It seemed to me that Junio's suggestion made the most amount of sense, but I tinkered with the with the warning message to make it clear that the cause of the warning was a bugus tool in the merge.tool configuration parameter. This has also been pushed out to git://repo.or.cz/git/mergetool.git Junio, please pull if you approve... - Ted commit d6678c28e30e836449092a2917d4b0bd6254b06c Author: Theodore Ts'o <tytso@mit.edu> Date: Sun Mar 18 22:30:10 2007 -0400 mergetool: pri...

gvimdiff is pretty cool. Have a look at the archives, I asked recently how to perform this, and a few solutions came out (you need a sane shell, and the abilities to create fifos). I'd use it everyday if a true vim/gvim explorer plugin would exist (and it's hard to code!). -- Christian -