git add? merge? rebase? No, I have a sneakier place to invoke gc. Whenever $EDITOR gets invoked. Heck, whenever git is waiting for any user input, do some gc in the background, it'd just have to be incremental so that we could pick up where we left off. Similarly, you could mix it in with git pull/push so that while we are waiting on the network, we can do some packing. Course, this wouldn't work for all repositories. -

Kristian Høgsberg pointed out that the two file modifications we were doing during the 'creating initial files' step are not even used within the test suite. This was actually confusing as we do not even need these changes for the tests to pass. All that really matters here is the specific commit dates are used so that these appear in the branch's reflog, and that the dates are different so that the branch will update when asked and the reflog entry is also updated. There is no need for the file ...

This needs major work to be usable. Although fast-import knows object name of each blob, being a quick-and-dirty patch, git-add does not ask for it and still computes the blob names by itself. The only thing this proof-of-concept patch buys is that the resulting object database is packed, and does not get loose objects. -

Yea. It doesn't actually matter in this test. The following patch can be applied and the test will still pass: diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh index c4c0dfa..ce045b2 100755 --- a/t/t1400-update-ref.sh +++ b/t/t1400-update-ref.sh @@ -198,11 +198,9 @@ test_expect_success \ GIT_AUTHOR_DATE="2005-05-26 23:41" \ GIT_COMMITTER_DATE="2005-05-26 23:41" git-commit -F M -a && h_OTHER=$(git rev-parse --verify HEAD) && - echo FIXED >F && ...

Signed-off-by: Kristian Høgsberg <krh@redhat.com> --- builtin-rerere.c | 16 ++++++++++++++++ builtin-tag.c | 3 +-- commit.h | 1 + strbuf.h | 1 + 4 files changed, 19 insertions(+), 2 deletions(-) diff --git a/builtin-rerere.c b/builtin-rerere.c index 29d057c..eb22a28 100644 --- a/builtin-rerere.c +++ b/builtin-rerere.c @@ -415,6 +415,22 @@ static int is_rerere_enabled(void) return 1; } +/* Export for builtin-commit. */ +int rerere(void) +{ + ...

Still defaults to stdout, but you can now override wt_status.fp after calling wt_status_prepare(). Signed-off-by: Kristian Høgsberg <krh@redhat.com> --- color.c | 18 ++++++------ color.h | 4 +- wt-status.c | 85 ++++++++++++++++++++++++++++++---------------------------- wt-status.h | 3 ++ 4 files changed, 58 insertions(+), 52 deletions(-) diff --git a/color.c b/color.c index 09d82ee..124ba33 100644 --- a/color.c +++ b/color.c @@ -135,39 +135,39 @@ int git_config...

Also, expose strbuf_add() and strbuf_add_char() to add raw data to the buffer. Signed-off-by: Kristian Høgsberg <krh@redhat.com> --- strbuf.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++------ strbuf.h | 3 ++ 2 files changed, 65 insertions(+), 7 deletions(-) diff --git a/strbuf.c b/strbuf.c index e33d06b..2805c11 100644 --- a/strbuf.c +++ b/strbuf.c @@ -11,16 +11,26 @@ static void strbuf_begin(struct strbuf *sb) { strbuf_init(sb); } -static void inline s...

This function reads from a given fd into a strbuf until end of file. Signed-off-by: Kristian Høgsberg <krh@redhat.com> --- strbuf.c | 19 +++++++++++++++++++ strbuf.h | 1 + 2 files changed, 20 insertions(+), 0 deletions(-) diff --git a/strbuf.c b/strbuf.c index 2805c11..fcfc05e 100644 --- a/strbuf.c +++ b/strbuf.c @@ -50,6 +50,25 @@ void read_line(struct strbuf *sb, FILE *fp, int term) { strbuf_end(sb); } +int strbuf_read_fd(struct strbuf *sb, int fd) +{ + int len, tot...

Several external projects (e.g. parsecvs) need libgit library and related header files. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> --- Makefile | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 51af531..d50e30b 100644 --- a/Makefile +++ b/Makefile @@ -143,6 +143,8 @@ STRIP ?= strip prefix = $(HOME) bindir = $(prefix)/bin +libdir = $(prefix)/lib +includedir = $(prefix)/include gitexecdir = $(bindir) sharedir =...

Your patch shows that our Makefile has been lacking a necessary dependency for a long time. LIB_H is not "public headers list", but more like "the headers everybody depends on", and the header file should have been on that list. Thanks. I am however not convinced it is a good idea to treat libgit.a as if it is a library. It is not a library in the usual sense of the word. Originally we did libgit.a primarily so that we do not have to list all the *.o dependencies in the Makefile out of lazin...

On GNU/Linux, libdir is used to mean "/usr/lib or /usr/lib64" depending on architecture. Different libdir meaning breaks idiomatic expressions like rpm specfile "make libdir=%_libdir". Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> --- git-gui/Makefile | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/git-gui/Makefile b/git-gui/Makefile index 1bac6fe..f143b2c 100644 --- a/git-gui/Makefile +++ b/git-gui/Makefile @@ -76,8 +76,8 @@ SHELL_PATH_SQ = ...

Do not commit an unchanged tree in non-merge mode. While regular mode is already handled by git-runstatus, this cheap check allows to avoid costly git-runstatus later. Also, amend mode needs special attention, because git-runstatus return value is ignored. The idea is that amend should not commit an unchanged tree, one should just remove the top commit using git-reset instead. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> --- git-commit.sh | 10 ++++++++++ 1 files changed, 10 inse...

By default, git-commit runs git-runstatus to print changes between the index and the working tree. This operation is very costly and is not always necessary. New option allows user to commit without running git-runstatus when appropriate. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> --- Documentation/git-commit.txt | 7 ++++++- git-commit.sh | 11 ++++++++++- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/Documentation/git-commit.txt b/Documenta...

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> --- git-rebase.sh | 18 ++++++++++++++---- 1 files changed, 14 insertions(+), 4 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index 3bd66b0..81c48d1 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -253,23 +253,33 @@ else fi # The tree must be really really clean. -git update-index --refresh || exit +git update-index --refresh || { + rm -rf .dotest + exit 1 +} + diff=$(git diff-index --cached --name-stat...

Hi, Being a pervert abusing the way subversion doesn't deal with branches and tags, I'm actually not a user of git-svn or git-svnimport, because they just can't deal easily with my perversion. So I'm writing a script to do the conversion for me, and since I also like to learn new things when I'm coding, I'm writing it in ruby. Anyways, one of the things I'm trying to convert is my svk repository for debian packaging of xulrunner (so, a significant subset of the mozilla tree), which doesn't invol...

Me too. I think its bad enough that fast-import knows the I agree. This is *exactly* what fast-import was built for. It really would be the better tool to use here. Much better than reinventing the wheel. Its already been invented twice for you in Git (normal object creation path and fast-import path). No need to do it a third time. -- Shawn. -

Aside from getting the hashes back from fast-import, that's what fast-import is for. I could also make it disable writing. Hmm. Junio and I were just talking about making fast-import send the marks table back out on stdout. This would make it easier for a frontend process to stream a whole bunch of objects into the process, then get back all of their SHA-1s. Less context switches and more parallel operation. -- Shawn. -

If there are no remotes, return empty list, not None. The later doesn't work with builtin set(). This fixes t1001-branch-rename.sh Signed-off-by: Pavel Roskin <proski@gnu.org> --- stgit/git.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/stgit/git.py b/stgit/git.py index 4b4c626..f847cce 100644 --- a/stgit/git.py +++ b/stgit/git.py @@ -953,7 +953,7 @@ def __remotes_from_dir(dir): if os.path.exists(d): return os.listdir(d) else: ...

At first glance this seems reasonable. I didn't know about git-log --first-parent until now, but it seems like a good 80% solution. Ideally, we'd probably stop, say something and give the user the choice of branches if multiple parents available. -- Eric Wong -

Which can get cleaned up when the next repack starts. This is no different from unfinished files accumulating from aborted/killed manual Git handles this already: $ git-gc fatal: unable to create '.git/packed-refs.lock': File exists error: failed to run pack-refs Quite true, but that's already impossible, so not a problem. One other thing: The heuristics for this can be such that users who are already regularly running git-gc by hand will see no change in behavior. Their repos wil...

A bad idea which one can turn optionally off remains a bad idea for everyone that has not been bitten enough by it already to actually look up the problem and remedy. Make this a warning. -- David Kastrup -

I do it from time to time. Seldom in working repositories, because they usually come and go before they have a chance to accumulate enough of loose objects. I do a partial repack (git repack -d) after every import from p4 repo, because every snapshot of it is an ugly mess changing files all over the tree. Sometimes, after I merged a big chunk with the p4 repo and sent it over (the process involves rebase). It is usually concious decision when to do a repack or gc. The repack time is seldom a prob...

YES! yikes. This is about the best argument put forth so far for not automatically running git-gc. Personally, I think git-gc should not remove unreferenced objects without --prune (but I haven't done anything about it). But even if git-gc was modified in this way, an occasional git-gc --prune would still be necessary to remove all of the unreferenced and dangling objects safely with a human thinking about the shared repo implications (unless shared repo handling is modified). -brandon ...

The problem here is that the clone could be having refs on objects from the origin that don't have refs left there. git-gc might, at some point, prune these refs, and the clone would have dangling refs. That could easily happen, for example, if you rebase a branch in the origin, but still have a clone with the original branch. Mike -

Guilty as charged. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -