Tried to build git 1.4.4.1 away from the source directory -- said make configure -- which made a configure, switched to a separate build/ directory, invoked that/../configure -- which ran fine, except produced no Makefile! What's the way to build git outside from the source directory? Cheers, Alexy -

I'm no sure that's supported right now. Someone tried to submit patches for it but I don't think they were applied. The configure script is really just a way to create a personal config.mak, which is the "real" way to configure Git prior to compiling it with Makefile. -- Shawn. -

if the SHA1 of our head matches the last SHA1 seen in the DB, avoid further processing. Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> --- git-cvsserver.perl | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/git-cvsserver.perl b/git-cvsserver.perl index df39512..0b75f9c 100755 --- a/git-cvsserver.perl +++ b/git-cvsserver.perl @@ -2184,7 +2184,10 @@ sub update # first lets get the commit list $ENV{GIT_DIR} = $self->{git_path}; - ...

Push does not do any working tree operation, so you _could_ detach the HEAD to point at the commit that used to be at the tip of the branch and advance the tip of the branch as the push instructs. The user could start a new branch out of the detached HEAD (which is behind the tip of the original branch), make necessary commits and then merge that branch locally to the branch the push advanced if s/he wants to. However, I am not sure if that is easy to understand for the users. It would be sane...

There is no reason not to, really. Signed-off-by: Junio C Hamano <junkio@cox.net> --- diff --git a/Documentation/git-pack-refs.txt b/Documentation/git-pack-refs.txt index 5da5105..464269f 100644 --- a/Documentation/git-pack-refs.txt +++ b/Documentation/git-pack-refs.txt @@ -7,7 +7,7 @@ git-pack-refs - Pack heads and tags for efficient repository access SYNOPSIS -------- -'git-pack-refs' [--all] [--prune] +'git-pack-refs' [--all] [--no-prune] DESCRIPTION ----------- @@ -40,1...

Signed-off-by: Yann Dirson <ydirson@altern.org> --- Here is a small helper script implementing the display of current/named/all stgit stacks (or standard branches) in gitk. As noted earlier, that does not allow to see new refs by requesting an update from gitk, but it will still be useful to me at least :) contrib/stg-gitk | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 59 insertions(+), 0 deletions(-) diff --git a/contrib/stg-gitk b/contrib/stg-gi...

Updates to the previous "remaining issues" list before 1.5.0. * Bare repository. I think what I have in 'next' to add 'core.bare' configuration to make the bare repository detection safer is ready to be used to port the RFC patch from Shawn to forbid working-tree operations in a bare repository to prevent accidents from happening. It would be nice if we can cook it for a few days in 'next' and push it out to 'master' before v1.5.0-rc1. Volunteers? * Packed refs. 'git-pack-refs' should...

Since v0.11, StGIT creates references to keep a hand on patch logs. This has the unfortunate side-effect that "gitk --all" suddenly shows all those very annoying, and soon becomes unusable on repositories for which was very convenient. I guess it would be acceptable to have stgit itself launch gitk with the correct options. The only way I could find to suppress these refs from the display is to find the refs ourselves and pipe them to gitk using --stdin: find .git/refs/ -type f -not -name '*....

Thanks. Will apply. -

I think it is Ok to give hints for untracked files -- with experience eyes will learn to ignore them but by then they do not need hints. Please send in a correction as appropriate. -

We need to check that the writes we perform during the update of the users configuration work. Convert to using write_in_full(). Signed-off-by: Andy Whitcroft <apw@shadowen.org> --- diff --git a/config.c b/config.c index 5cbd130..2c9d07c 100644 --- a/config.c +++ b/config.c @@ -464,7 +464,15 @@ static int store_aux(const char* key, const char* value) return 0; } -static void store_write_section(int fd, const char* key) +static int write_error() +{ + fprintf(stderr, "Failed to ...

We have a number of badly checked read() calls. Often we are expecting read() to read exactly the size we requested or fail, this fails to handle interrupts or short reads. Add a read_in_full() providing those semantics. Otherwise we at a minimum need to check for EINTR and EAGAIN, where this is appropriate use xread(). Signed-off-by: Andy Whitcroft <apw@shadowen.org> --- diff --git a/builtin-grep.c b/builtin-grep.c index 3b1b1cb..2bfbdb7 100644 --- a/builtin-grep.c +++ b/builtin-grep...

I just pulled and built 'next' and it reported a version number of 1.4.4.4.g71bb6 -- and not one v1.5.0-rc0.g71bb6. I can understand why, since it found the changes pulled in from the maint branch before it found the v1.5.0-rc0 tag --- but it could be more than a little misleading. Is this something that can be fixed in any way, short of finding all of the tags reachable from HEAD and then doing a sort? That seems like a gross kludge, but I can't think of any other way of fixing it. - Ted...

I was assuming either lexigraphically, or via some really complicated Yeah, that is the question. If we're willing to look at the tag name, it's pretty clear that if both v1.5.0-rc0 and v1.4.4.4 is reachable from the head, it should be based on the "newer" version, i.e., v1.5.0-rc0. A human can figure this out easily, but algorithimically we end up having to use something like the rpm or dpkg version comparison algorithm, both of which are hueristics that will sometimes get thigns wrong. ...

I tried set-tree now, and all I got was a perl crash: morpheus% git svn set-tree master.. diff-tree 8dba2b29df78184fef96bbbf9521387846b140b3 b5561ab7309e9b7b3acfacaa786358e7d90665c6 A .gitignore ... more files Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/SVN/Core.pm line 579. Malformed file: at /usr/local/bin/git-svn line 459 This is git f4bf2184ae8b79f95b9f56c1ea5455d04e559299 from Jan 1. Perl is v5.8.8 (Ubunty edgy) -- David Kågedal - ...

So if I want to commit a different subset, is that possible? In my case, I have a "master" branch with a few changes on top of git-svn that I never want to commit to svn. So what I want is to commit "master..HEAD". Can I do that with dcommit? It seems that "git svn set-tree master..HEAD" might do the trick. -- David Kågedal -

Guilt v0.17 is available for download. Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git Overall, a lot of good changes that make the whole porcelain more robust. The most notable one is the format of the status file (lists pushed patches) which now also includes the hash of the comm...

With this patch, cvsimport will skip commits made in the last 10 minutes. The recent-ness test is of 5 minutes + cvsps fuzz window (5 minutes default). To force recent commits to be imported, pass the -a(ll) flag. When working with a CVS repository that is in use, importing commits that are too recent can lead to partially incorrect trees. This is mainly due to - Commits that are within the cvsps fuzz window may later be found to have affected more files. - When performing incremental...

Correction: it is -p ' -x ' that you need to pass. Things _are_ saner here with it. YMMV. cheers, martin -

Hi, My reasoning is that invalid entries should rather be ignored than be taken into account. So, to verify that you are not walking invalid data, you have to parse it anyway. Ciao, Dscho -

Something I just thought of: ATA and SCSI hard disks do their own read-ahead. Seeking all over the place to pick up bits of directory will hurt even more with the disk reading and throwing away data (albeit in its internal elevator and cache). Jeff -

And they usually won't readahead if there is another command to process, though they can be set up to read unrequested data in spite of outstanding commands. When they are reading ahead, they'll only fetch LBAs beyond the last request until a buffer fills or the readahead gets interrupted. jeremy -

It will help a little; e2fsck -D compresses the logical view of the directory, but it doesn't optimize the physical layout on disk at all, and of course, it won't help with the lack of readahead logic. It's possible to improve how e2fsck -D works, at the moment, it's not trying to make the directory be contiguous on disk. What it should probably do is to pull a list of all of the blocks used by the directory, sort them, and then try to see if it can improve on the list by allocating some new bloc...

I wasn't proposing to move other data blocks around in order make the directory be contiguous, but just a "quick and dirty" try to make things better. But yes, in order to really fix layout issues you would have to do a full defrag, and it's probably more important that we try to fix things so that defragmentation runs aren't necessary in the first place.... - Ted -

Heh, well perhaps I should use the original for a while longer and see if I get used to it. Of course I mostly use git on git and linux which both tend to have "error" in their titles :). -apw -