* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Shawn Pearce @ 2006-12-19 7:58 UTC (permalink / raw)
To: Marco Roeland
Cc: Linus Torvalds, Theodore Tso, Nicolas Pitre, Randal L. Schwartz,
git
In-Reply-To: <20061219075256.GA30448@fiberbit.xs4all.nl>
Marco Roeland <marco.roeland@xs4all.nl> wrote:
> The kernel git repository isn't very handy on the Mac HFS+ filesystem,
> due to it being case-insensitive, but I suppose it won't influence
> git-index-pack.
Yea, I just play with it in packed format on this system. :-)
--
^ permalink raw reply
* Re: git-svn: follow parent after the fact?
From: Eric Wong @ 2006-12-19 7:47 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <45873D0A.1040804@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> One of the other git users here just noticed that his git-svn clone of a
> particular svn repo has an inconsistent set of files compared to the svn
> client. Turns out the repo has had its trunk moved around in the past. A
> fresh clone with --follow-parent (which he didn't use) produces the
> correct results.
The final set of files at the latest (svn) revision was inconsistent?
That should never happen... If so, I'd very much like to look into this.
> Obviously he can blow away his current repo and make a new one, but it'd
> be nicer if he could preserve his local change history. Is there any way
> to retroactively apply the additional changes --follow-parent would have
> applied if it had been used on the initial fetch?
git-svn graft-branches can probably work (if he imported the parent
separately).
> It would be better, IMO, if you didn't have to figure out whether or not
> a given remote svn repository has had branch renames in the past in
> order to figure out if you need to provide an extra option to git-svn
> fetch. Maybe --follow-parent should be the default behavior and there
> should be an option to turn it off? Or is there a good reason to not
> want that behavior most of the time? My assumption is that it's not the
> default simply because it's a recent addition.
It may behave unpredictably on some poorly organized repositories. I
haven't quite debugged this problem fully as the current code to handle
multiple repositories is a hacked-on mess.
I'm currently refactoring git-svn to work better on multi-remote
operations and --follow-parent should be easier to debug as a result.
> By the way, I'm completely in favor of renaming commit to set-tree. +1
> for that change.
Noted, thanks for the input.
--
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Shawn Pearce @ 2006-12-19 7:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Tso, Nicolas Pitre, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612182248420.3479@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Tue, 19 Dec 2006, Shawn Pearce wrote:
> >
> > Why isn't git-index-pack doing the same? Is there some hidden glitch
> > in some OS somewhere that has a problem with overmapping a file and
> > appending into it via write()? I've done that on Mac OS X, Linux,
> > BSDi, Solaris... never had a problem.
>
> It works on modern systems, but at least old HPUX versions had
> non-coherent mmap() and write(), and POSIX does not guarantee it. And if
> you ever want to port to Windows, I don't think you should do it.
>
> Anyway, try the pread() version first, see if that fixes the OS X problem.
I'll give your pread() version a shot.
But right now I'm in the middle of cloning your linux-2.6 git
repository.
It is done downloading the pack and my system is pegged at 100%
CPU while resolving deltas.
ActivityMonitor is showing that I'm spending 94% CPU in the kernel,
which is just insane. Clearly Mac OS X's kernel cannot gracefully
handle what git-index-pack is currently doing.
--
^ permalink raw reply
* Re: [PATCH] Only warn about missing branch.<n>.merge in pull.
From: Shawn Pearce @ 2006-12-19 6:54 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
In-Reply-To: <20061218202803.GB28925@mellanox.co.il>
"Michael S. Tsirkin" <mst@mellanox.co.il> wrote:
> > Quoting r. Junio C Hamano <junkio@cox.net>:
> > I can see a few possibilities:
> >
> > (1) people do not interact with multiple remote repositories
> > regularly, so this is not a problem in practice.
> >
> > (2) people do, but "the first branch listed" rule is good
> > enough in practice. Because they would always say "git
> > pull second which-branch" instead if they want something
> > different, this is a non-issue.
> >
> > (3) branch.$current.merge was a mistake. It should have been
> > branch.$current.merge.$remote. In other words, the
> > configuration should have been about the current branch and
> > the remote repository pair.
> >
> > (4) the current configuration mechanism is fine, but the code
> > is not. We should forbid "the first branch listed" rule
> > from being applied for "git pull second", and require the
> > users to explicitly say which branch(es) to merge.
> >
> > I am inclined to say that (1) is possible, (2) is implausible
> > (otherwise we would not have done 62b339a5 for the same reason),
> > (3) is confused, and probably (4) is what we need.
>
> As a person who tracks multiple remotes in one repository,
> I would say (4) best matches what I do.
>
> So I currently always do git fetch <remote> to download changes,
> and always use git pull . <branch> to merge a specific branch.
Agreed; #4 best matches what I (and those I work with on that ugly
repository of mine) do.
My git.git repository currently just fetches all of Junio's branches
right into my local refs/heads. I fetch every day or so, but never
merge from next into any branch. Though I create branches off next,
master, or some select commit based on whatever topic I'm hacking.
In my other repositories I tend to fetch before merging, for a
number of reasons:
a) Its distributed backup; if I fetch the branch that's one more copy.
b) I can easily view a branch's recent changes, but not affect my
own topics until I'm ready to take them in. People often ask
me to look at their changes, or wonder why something is suddenly
acting odd - looking at the commits in gitk usually tells me
quite quickly who did what. :-)
c) I can easily start a new topic off any recent change.
d) I can easily merge topics once they are local and reviewed.
a,b,d are not quite as necessary in an email-patch based group such
as git itself, as the mailing list offers most of the reasons I
fetch first. b and c are just convience there.
--
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Linus Torvalds @ 2006-12-19 6:51 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Theodore Tso, Nicolas Pitre, Randal L. Schwartz, git
In-Reply-To: <20061219063930.GA2511@spearce.org>
On Tue, 19 Dec 2006, Shawn Pearce wrote:
>
> Why isn't git-index-pack doing the same? Is there some hidden glitch
> in some OS somewhere that has a problem with overmapping a file and
> appending into it via write()? I've done that on Mac OS X, Linux,
> BSDi, Solaris... never had a problem.
It works on modern systems, but at least old HPUX versions had
non-coherent mmap() and write(), and POSIX does not guarantee it. And if
you ever want to port to Windows, I don't think you should do it.
Anyway, try the pread() version first, see if that fixes the OS X problem.
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Linus Torvalds @ 2006-12-19 6:47 UTC (permalink / raw)
To: Theodore Tso; +Cc: Nicolas Pitre, Randal L. Schwartz, git
In-Reply-To: <20061219051108.GA29405@thunk.org>
On Tue, 19 Dec 2006, Theodore Tso wrote:
>
> Actually, depending on the size of the chunk, even on Linux
> malloc/read/free can be faster than the mmap/munmap
Yes.
In general, mmap/munmap is faster only if:
- you access the same data multiple times within one page (ie a single
page-fault will actually result in more than one access)
OR
- you can use it to avoid management overhead (ie you know your data is
going to accessed very sparsely, but you don't know the patterns, and
trying to keep track of it is painful as hell)
That said, under Linux, mmap is almost never really _slower_ either, which
is why this issue never made any real difference. The overhead of doing
page table manipulation is pretty much balanced out by the overhead of
doing a memcpy.
But that "mmap is fast" is _not_ true on many other operating systems,
which is why it might be worthwhile to try something like the appended on
OS X, which uses pread() instead of mmap().
This is _not_ very much tested. It seems to work. Caveat emptor. It would
be interesting to hear if many small "pread()" calls are faster than many
mmap/munmap calls on OS X. I bet they are. Under Linux, there should be
almost no difference.
Linus
---
diff --git a/index-pack.c b/index-pack.c
index 6d6c92b..094f8b2 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -8,6 +8,7 @@
#include "tree.h"
#include <sys/time.h>
#include <signal.h>
+#include <unistd.h>
static const char index_pack_usage[] =
"git-index-pack [-v] [-o <index-file>] [{ ---keep | --keep=<msg> }] { <pack-file> | --stdin [--fix-thin] [<pack-file>] }";
@@ -279,27 +280,25 @@ static void *get_data_from_pack(struct object_entry *obj)
{
unsigned long from = obj[0].offset + obj[0].hdr_size;
unsigned long len = obj[1].offset - from;
- unsigned pg_offset = from % getpagesize();
- unsigned char *map, *data;
+ unsigned char *src, *data;
z_stream stream;
int st;
- map = mmap(NULL, len + pg_offset, PROT_READ, MAP_PRIVATE,
- mmap_fd, from - pg_offset);
- if (map == MAP_FAILED)
- die("cannot mmap pack file: %s", strerror(errno));
+ src = xmalloc(len);
+ if (pread(mmap_fd, src, len, from) != len)
+ die("cannot pread pack file: %s", strerror(errno));
data = xmalloc(obj->size);
memset(&stream, 0, sizeof(stream));
stream.next_out = data;
stream.avail_out = obj->size;
- stream.next_in = map + pg_offset;
+ stream.next_in = src;
stream.avail_in = len;
inflateInit(&stream);
while ((st = inflate(&stream, Z_FINISH)) == Z_OK);
inflateEnd(&stream);
if (st != Z_STREAM_END || stream.total_out != obj->size)
die("serious inflate inconsistency");
- munmap(map, len + pg_offset);
+ free(src);
return data;
}
^ permalink raw reply related
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Shawn Pearce @ 2006-12-19 6:39 UTC (permalink / raw)
To: Theodore Tso; +Cc: Nicolas Pitre, Linus Torvalds, Randal L. Schwartz, git
In-Reply-To: <20061219051108.GA29405@thunk.org>
Theodore Tso <tytso@mit.edu> wrote:
> On Mon, Dec 18, 2006 at 07:13:40PM -0500, Nicolas Pitre wrote:
> > Maybe. However the mmap() may occur on section of the pack file which
> > has just been written to in order to write even more, always to the same
> > file. On Linux this is fast because the mmap'd data is likely to still
> > be in the cache.
> >
> > I guess this could be turned into a malloc()/read()/free() with no
> > trouble.
>
> Actually, depending on the size of the chunk, even on Linux
> malloc/read/free can be faster than the mmap/munmap, because
> mmap/munmap calls involve page table manipulations, and even on Linux
> that is often slower or dead even with the memory copy involved with
> using malloc/read. Even when reading huge chunks of Canon Raw File
> data at a time, I found (experimentally) that it was no faster to use
> mmap() compared to read(). And for small chunks of data, malloc/read
> will definitely win out over mmap(), since the page table operations
> and resulting page faults completely trump the cost of copying the
> bytes from the page cache to the read() buffer.
This is why git-fast-import mmaps 128 MiB blocks from the file at
a time. The mmap region is usually much larger than the file itself;
the application appends to the file via write() then goes back
and rereads data when necessary via the already established mmap.
Its rare for the application to need to unmap/remap a different block
so there really isn't very much page table manipulation overhead.
Why isn't git-index-pack doing the same? Is there some hidden glitch
in some OS somewhere that has a problem with overmapping a file and
appending into it via write()? I've done that on Mac OS X, Linux,
BSDi, Solaris... never had a problem.
--
^ permalink raw reply
* Re: [PATCH] Add --remotes option to show-branch
From: Junio C Hamano @ 2006-12-19 5:50 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <5D50A3C0-4521-402B-ABD4-5698870A3BD2@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
>> I actually was thinking about removing these flags, not adding
>> --remotes, because
>>
>> git show-branch remotes/origin/*
>
> ... but --remotes is significantly easier than "remotes/
> origin/* remotes/partner/*". And sometimes I'd really like to know
> where all the branches are in relation to each other.
Actually, git show-branch origin/* would work equally well if
you do not have local "heads/origin/*" branches.
^ permalink raw reply
* Re: [PATCH] Small optimizations to gitweb
From: Junio C Hamano @ 2006-12-19 5:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Robert Fitzsimons
In-Reply-To: <200612190159.24173.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>> ...
>> The counting code in git_*_body is seriously unusual to tempt
>> anybody who reviews the code to reduce that 17 to 16.
>
> Well, this should be then corrected perhaps to
Well, I did not say it was _wrong_, just unusual, so there is
nothing to fix.
>> By the way, I wonder how that $extra is omitted when $revlist is
>> longer than $to; it should be a trivial fix but it seems to me
>> that it is always spitted out with the current code.
>
> We should check if we want to omit $extra, either in caller or
> in callee, the *_body subroutine itself.
Check?
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Theodore Tso @ 2006-12-19 5:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612181906450.18171@xanadu.home>
On Mon, Dec 18, 2006 at 07:13:40PM -0500, Nicolas Pitre wrote:
> Maybe. However the mmap() may occur on section of the pack file which
> has just been written to in order to write even more, always to the same
> file. On Linux this is fast because the mmap'd data is likely to still
> be in the cache.
>
> I guess this could be turned into a malloc()/read()/free() with no
> trouble.
Actually, depending on the size of the chunk, even on Linux
malloc/read/free can be faster than the mmap/munmap, because
mmap/munmap calls involve page table manipulations, and even on Linux
that is often slower or dead even with the memory copy involved with
using malloc/read. Even when reading huge chunks of Canon Raw File
data at a time, I found (experimentally) that it was no faster to use
mmap() compared to read(). And for small chunks of data, malloc/read
will definitely win out over mmap(), since the page table operations
and resulting page faults completely trump the cost of copying the
bytes from the page cache to the read() buffer.
^ permalink raw reply
* Re: [PATCH] Add --remotes option to show-branch
From: Brian Gernhardt @ 2006-12-19 5:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfybdvsq7.fsf@assigned-by-dhcp.cox.net>
On Dec 18, 2006, at 3:45 PM, Junio C Hamano wrote:
> I've never used --heads and --tags myself because
>
> git show-branch heads/*
> git show-branch tags/*
>
> works perfectly well for me, and it often is not very useful to
> look at _all_ the heads (tags are even much less interesting) in
> a topic heavy repository anyway. IOW, I more often do something
> like:
>
> git show-branch --topics master heads/js/*
>
> to see what Johannes has relative to "master".
>
> I actually was thinking about removing these flags, not adding
> --remotes, because
>
> git show-branch remotes/origin/*
I agree that tags/* is fairly useless. Way too much data. And if
you want to remote --heads and --tags, then --remotes doesn't have
much place. I was simply poking around and thought that if we have
those two, then the third seemed natural and odd to miss.
However if --all meant all heads, local or remote, I'd be fairly
pleased. heads/* is just as easy as --heads (and leaving it blank is
even easier), but --remotes is significantly easier than "remotes/
origin/* remotes/partner/*". And sometimes I'd really like to know
where all the branches are in relation to each other.
Pardon if this doesn't make much sense. It's been a looooong day...
^ permalink raw reply
* branch rebase and push
From: SungHyun Nam @ 2006-12-19 3:39 UTC (permalink / raw)
To: git
Hello,
Can I push a branch after rebase?
I got a error message:
error: remote 'refs/heads/br' is not a strict subset of local ref
'refs/heads/br'. maybe you are not up-to-date and need to pull first?
It worked fine if I did:
$ git checkout -b br
$ git pull . master
$ git checkout master
$ git pull
$ git push
But I got above error message if I did:
$ git checkout br
$ git rebase master
$ git checkout master
$ git pull
$ git push
Thanks.
namsh
^ permalink raw reply
* Re: [PATCH] git-parse-remote: fix ambiguous shell bug in expand_refs_wildcard
From: Herbert Xu @ 2006-12-19 0:35 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20061218224505.GB13034@coredump.intra.peff.net>
On Mon, Dec 18, 2006 at 05:45:05PM -0500, Jeff King wrote:
>
> but doing it inside an interpolated string doesn't:
>
> $ foo=bar}
> $ echo "${foo%'}'}"
> bar}'}
Yes it's a bug in dash. Both quote marks (" and ') are represented
by the same char internally before processing which is where the
mix-up occurs.
I'll work on a fix.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
^ permalink raw reply
* Re: [PATCH 2/2] Protect commits recorded in reflog from pruning.
From: Junio C Hamano @ 2006-12-19 1:22 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061218140813.GA32446@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> This teaches fsck-objects and prune to protect objects referred
>> to by reflog entries.
>
> Nice!
>
> But its not enough.
>
> $ git-repack -a -d
> $ git reset --hard HEAD^
> $ git-repack -a -d
> $ git reset --hard HEAD@{1}
>
> that last reset would fail now, wouldn't it? pack-objects needs
> to know it should be pulling in the objects stuff reachable from
> reflogs too.
Sure.
-- >8 --
Teach git-repack to preserve objects referred to by reflog entries.
This adds a new option --reflog to pack-objects and revision
machinery; do not bother documenting it for now, since this is
only useful for local repacking.
When the option is passed, objects reachable from reflog entries
are marked as interesting while computing the set of objects to
pack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-pack-objects.c | 3 +-
git-repack.sh | 2 +-
revision.c | 56 ++++++++++++++++++++++++++++++++++++++++++------
3 files changed, 52 insertions(+), 9 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index a2dc7d1..928684b 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -19,7 +19,7 @@ static const char pack_usage[] = "\
git-pack-objects [{ -q | --progress | --all-progress }] \n\
[--local] [--incremental] [--window=N] [--depth=N] \n\
[--no-reuse-delta] [--delta-base-offset] [--non-empty] \n\
- [--revs [--unpacked | --all]*] [--stdout | base-name] \n\
+ [--revs [--unpacked | --all]*] [--reflog] [--stdout | base-name] \n\
[<ref-list | <object-list]";
struct object_entry {
@@ -1577,6 +1577,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
}
if (!strcmp("--unpacked", arg) ||
!strncmp("--unpacked=", arg, 11) ||
+ !strcmp("--reflog", arg) ||
!strcmp("--all", arg)) {
use_internal_rev_list = 1;
if (ARRAY_SIZE(rp_av) - 1 <= rp_ac)
diff --git a/git-repack.sh b/git-repack.sh
index 067898f..375434b 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -62,7 +62,7 @@ case ",$all_into_one," in
esac
args="$args $local $quiet $no_reuse_delta$extra"
-name=$(git-pack-objects --non-empty --all $args </dev/null "$PACKTMP") ||
+name=$(git-pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
exit 1
if [ -z "$name" ]; then
echo Nothing new to pack.
diff --git a/revision.c b/revision.c
index 993bb66..cbf1045 100644
--- a/revision.c
+++ b/revision.c
@@ -462,21 +462,59 @@ static void limit_list(struct rev_info *revs)
revs->commits = newlist;
}
-static int all_flags;
-static struct rev_info *all_revs;
+struct all_refs_cb {
+ int all_flags;
+ struct rev_info *all_revs;
+ const char *name_for_errormsg;
+};
static int handle_one_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
{
- struct object *object = get_reference(all_revs, path, sha1, all_flags);
- add_pending_object(all_revs, object, "");
+ struct all_refs_cb *cb = cb_data;
+ struct object *object = get_reference(cb->all_revs, path, sha1,
+ cb->all_flags);
+ add_pending_object(cb->all_revs, object, "");
return 0;
}
static void handle_all(struct rev_info *revs, unsigned flags)
{
- all_revs = revs;
- all_flags = flags;
- for_each_ref(handle_one_ref, NULL);
+ struct all_refs_cb cb;
+ cb.all_revs = revs;
+ cb.all_flags = flags;
+ for_each_ref(handle_one_ref, &cb);
+}
+
+static int handle_one_reflog_ent(unsigned char *osha1, unsigned char *nsha1, char *detail, void *cb_data)
+{
+ struct all_refs_cb *cb = cb_data;
+ struct object *object;
+
+ if (!is_null_sha1(osha1)) {
+ object = get_reference(cb->all_revs, cb->name_for_errormsg,
+ osha1, cb->all_flags);
+ add_pending_object(cb->all_revs, object, "");
+ }
+ object = get_reference(cb->all_revs, cb->name_for_errormsg,
+ nsha1, cb->all_flags);
+ add_pending_object(cb->all_revs, object, "");
+ return 0;
+}
+
+static int handle_one_reflog(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct all_refs_cb *cb = cb_data;
+ cb->name_for_errormsg = path;
+ for_each_reflog_ent(path, handle_one_reflog_ent, cb_data);
+ return 0;
+}
+
+static void handle_reflog(struct rev_info *revs, unsigned flags)
+{
+ struct all_refs_cb cb;
+ cb.all_revs = revs;
+ cb.all_flags = flags;
+ for_each_ref(handle_one_reflog, &cb);
}
static int add_parents_only(struct rev_info *revs, const char *arg, int flags)
@@ -803,6 +841,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
handle_all(revs, flags);
continue;
}
+ if (!strcmp(arg, "--reflog")) {
+ handle_reflog(revs, flags);
+ continue;
+ }
if (!strcmp(arg, "--not")) {
flags ^= UNINTERESTING;
continue;
^ permalink raw reply related
* git-svn: follow parent after the fact?
From: Steven Grimm @ 2006-12-19 1:14 UTC (permalink / raw)
To: git
One of the other git users here just noticed that his git-svn clone of a
particular svn repo has an inconsistent set of files compared to the svn
client. Turns out the repo has had its trunk moved around in the past. A
fresh clone with --follow-parent (which he didn't use) produces the
correct results.
Obviously he can blow away his current repo and make a new one, but it'd
be nicer if he could preserve his local change history. Is there any way
to retroactively apply the additional changes --follow-parent would have
applied if it had been used on the initial fetch?
It would be better, IMO, if you didn't have to figure out whether or not
a given remote svn repository has had branch renames in the past in
order to figure out if you need to provide an extra option to git-svn
fetch. Maybe --follow-parent should be the default behavior and there
should be an option to turn it off? Or is there a good reason to not
want that behavior most of the time? My assumption is that it's not the
default simply because it's a recent addition.
By the way, I'm completely in favor of renaming commit to set-tree. +1
for that change.
^ permalink raw reply
* Re: [PATCH] Only warn about missing branch.<n>.merge in pull.
From: Junio C Hamano @ 2006-12-19 1:14 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <200612190159.58658.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Monday 18 December 2006 21:43, Johannes Schindelin wrote:
>>
>> However, I would actually reuse our versatile (often hated?) config
>> handling:
>>
>> [branch "xyz"]
>> remote = blabla # this is the default remote
>> merge = master # this is the default branch for the default remote
>> merge = pu for remote second # merge 'pu' if pulling from second
>
> Looks a little bit confusing, but is fine with me.
> I even would remove the need for the word "remote" in the second merge line.
> Anybody using this has to look it up in the documentation, anyway.
> Because these options are not really self-describing.
I actually am in favor of Johannes's one, except that it does
look like you are always making a pentapus merge of pu, for,
remote and second branches into xyz ;-).
^ permalink raw reply
* [PATCH] Move "no merge candidate" warning into git-pull
From: Josef Weidendorfer @ 2006-12-19 1:01 UTC (permalink / raw)
To: git
In-Reply-To: <20061218081631.GA9727@spearce.org>
The warning triggered even when running "git fetch" only
when resulting .git/FETCH_HEAD only contained
branches marked as 'not-for-merge'.
Signed-off-by: Josef Weidendorfer <weidendo@gmx.de>
---
[Resent to mailing list; I forgot to add it]
On Monday 18 December 2006 09:16, Shawn Pearce <spearce@spearce.org> wrote:
> Current 'next':
>
> $ git fetch
> Warning: No merge candidate found because value of config option
> "branch.sp/username-reflog.merge" does not match any remote branch fetched.
>
> uhhh.. i asked for a fetch, not a merge.
Oops.
I hope this does it right. Testing by the same person which does the patch
is obviously almost the same as not testing at all.
Josef
git-parse-remote.sh | 10 ----------
git-pull.sh | 4 ++++
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 6ae534b..d02f404 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -134,7 +134,6 @@ canon_refs_list_for_fetch () {
# or the first one otherwise; add prefix . to the rest
# to prevent the secondary branches to be merged by default.
merge_branches=
- found_mergeref=
curr_branch=
if test "$1" = "-d"
then
@@ -173,10 +172,6 @@ canon_refs_list_for_fetch () {
dot_prefix= && break
done
fi
- if test -z $dot_prefix
- then
- found_mergeref=true
- fi
case "$remote" in
'') remote=HEAD ;;
refs/heads/* | refs/tags/* | refs/remotes/*) ;;
@@ -197,11 +192,6 @@ canon_refs_list_for_fetch () {
fi
echo "${dot_prefix}${force}${remote}:${local}"
done
- if test -z "$found_mergeref" -a "$curr_branch"
- then
- echo >&2 "Warning: No merge candidate found because value of config option
- \"branch.${curr_branch}.merge\" does not match any remote branch fetched."
- fi
}
# Returns list of src: (no store), or src:dst (store)
diff --git a/git-pull.sh b/git-pull.sh
index e23beb6..1703091 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -76,6 +76,10 @@ merge_head=$(sed -e '/ not-for-merge /d' \
case "$merge_head" in
'')
+ curr_branch=$(git-symbolic-ref HEAD | \
+ sed -e 's|^refs/heads/||')
+ echo >&2 "Warning: No merge candidate found because value of config option
+ \"branch.${curr_branch}.merge\" does not match any remote branch fetched."
echo >&2 "No changes."
exit 0
;;
--
1.4.4.2.gee60-dirty
^ permalink raw reply related
* Re: [PATCH] Only warn about missing branch.<n>.merge in pull.
From: Josef Weidendorfer @ 2006-12-19 0:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.63.0612182135360.19693@wbgn013.biozentrum.uni-wuerzburg.de>
On Monday 18 December 2006 21:43, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 18 Dec 2006, Junio C Hamano wrote:
>
> > $ git pull second
> > ...
> > (3) branch.$current.merge was a mistake. It should have been
> > branch.$current.merge.$remote. In other words, the
> > configuration should have been about the current branch and
> > the remote repository pair.
> >
> > (4) the current configuration mechanism is fine, but the code
> > is not. We should forbid "the first branch listed" rule
> > from being applied for "git pull second", and require the
> > users to explicitly say which branch(es) to merge.
> I fetch/merge criss-crossed over my machines, so this affects me. Until
> the recent changes, I _always_ fetched/merged with explicit remote and
> branch. This keeps me unconfused about what I actually do.
>
> With the options you list, I'd say (3) with (4) as a fallback is the way
> to go.
I agree.
Despite of this, I just sent out the quick fix.
> However, I would actually reuse our versatile (often hated?) config
> handling:
>
> [branch "xyz"]
> remote = blabla # this is the default remote
> merge = master # this is the default branch for the default remote
> merge = pu for remote second # merge 'pu' if pulling from second
Looks a little bit confusing, but is fine with me.
I even would remove the need for the word "remote" in the second merge line.
Anybody using this has to look it up in the documentation, anyway.
Because these options are not really self-describing.
Josef
^ permalink raw reply
* Re: [PATCH] Small optimizations to gitweb
From: Jakub Narebski @ 2006-12-19 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Robert Fitzsimons
In-Reply-To: <7vbqm0vkd6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Actually, that is needed to implement checking if we have more than
>> the number of commits to show to add '...' at the end only if there
>> are some commits which we don't show.
>
> The counting code in git_*_body is seriously unusual to tempt
> anybody who reviews the code to reduce that 17 to 16.
>
> The caller says:
>
> git_shortlog_body(\@revlist, 0, 15, $refs,
> $cgi->a({-href => href(action=>"shortlog")}, "..."));
>
> If it counts up, especially if it counts from zero, the loop
> would usually say:
>
> for (i = bottom; i < end; i++)
>
> and anybody who reads that caller would expect it to show 15
> lines of output.
>
> But the actual code does this instead:
>
> sub git_shortlog_body {
> # uses global variable $project
> my ($revlist, $from, $to, $refs, $extra) = @_;
>
> $from = 0 unless defined $from;
> $to = $#{$revlist} if (!defined $to || $#{$revlist} < $to);
> ...
> for (my $i = $from; $i <= $to; $i++) {
> ... draw each item ...
> }
Well, this should be then corrected perhaps to
my ($revlist, $begin, $end, $refs, $extra) = @_;
$begin = 0 unless defined $from;
$end = scalar(@$revlist) if (!defined $end || @$revlist <= $end);
...
for (my $i = $begin; $i < $end; $i++) {
... draw each item ...
}
I thought that $from..$to ($from <= i <= $to) is more natural
and easier to understand than $begin..$end ($begin <= i < $end)...
guess I guessed wrong.
> if (defined $extra) {
> print "<tr>\n" .
> "<td colspan=\"4\">$extra</td>\n" .
> "</tr>\n";
> }
> }
>
> By the way, I wonder how that $extra is omitted when $revlist is
> longer than $to; it should be a trivial fix but it seems to me
> that it is always spitted out with the current code.
We should check if we want to omit $extra, either in caller or
in callee, the *_body subroutine itself.
--
Jakub Narebski
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Nicolas Pitre @ 2006-12-19 0:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612181511260.3479@woody.osdl.org>
On Mon, 18 Dec 2006, Linus Torvalds wrote:
> I've heard of other operations being slow on OS X - and two orders of
> magnitude really isn't unthinkable. I don't think people always seem to
> really understand how _good_ Linux is, and how much faster it can be. It's
> not just "Windows XP" sucks. Quite often it's literally "Linux is just
> damn fast".
>
> Sadly, that causes problems when the main developers don't even see any
> issues, just because the Linux kernel environment makes things look really
> really cheap. Even when it isn't always cheap on other platforms.
>
> Nico - have you looked at perhaps making the index-pack.c "mmap()" usage
> do chunking? Or just mmap the whole damn thing once? Linux is fast, but
> even Linux will be faster if you just mmap it once ;)
Maybe. However the mmap() may occur on section of the pack file which
has just been written to in order to write even more, always to the same
file. On Linux this is fast because the mmap'd data is likely to still
be in the cache.
I guess this could be turned into a malloc()/read()/free() with no
trouble.
^ permalink raw reply
* Re: [PATCH] Small optimizations to gitweb
From: Junio C Hamano @ 2006-12-18 23:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Robert Fitzsimons
In-Reply-To: <em77cg$obn$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Actually, that is needed to implement checking if we have more than
> the number of commits to show to add '...' at the end only if there
> are some commits which we don't show.
The counting code in git_*_body is seriously unusual to tempt
anybody who reviews the code to reduce that 17 to 16.
The caller says:
git_shortlog_body(\@revlist, 0, 15, $refs,
$cgi->a({-href => href(action=>"shortlog")}, "..."));
If it counts up, especially if it counts from zero, the loop
would usually say:
for (i = bottom; i < end; i++)
and anybody who reads that caller would expect it to show 15
lines of output.
But the actual code does this instead:
sub git_shortlog_body {
# uses global variable $project
my ($revlist, $from, $to, $refs, $extra) = @_;
$from = 0 unless defined $from;
$to = $#{$revlist} if (!defined $to || $#{$revlist} < $to);
...
for (my $i = $from; $i <= $to; $i++) {
... draw each item ...
}
if (defined $extra) {
print "<tr>\n" .
"<td colspan=\"4\">$extra</td>\n" .
"</tr>\n";
}
}
By the way, I wonder how that $extra is omitted when $revlist is
longer than $to; it should be a trivial fix but it seems to me
that it is always spitted out with the current code.
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Linus Torvalds @ 2006-12-18 23:28 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Nicolas Pitre, git
In-Reply-To: <8664c896xv.fsf@blue.stonehenge.com>
On Mon, 18 Dec 2006, Randal L. Schwartz wrote:
>
> Linus> You're running this under OS X, aren't you? It's a pig of an OS, but
> Linus> "almost one hour" vs "25 seconds" is still unreasonable.
>
> I agree!
The only thing that comes to mind is
- some actual difference in how the pack looks. Although I don't really
see that. I re-pack both my own private kernel repos and the kernel.org
one fairly often, and usually with a pretty recent git. I don't think
any of the packing heuristics have changed in a long time. And I just
checked: the kernel.org pack-file (the big one) unpacks quickly too.
- SHA1 library differences. Maybe OpenSSL on OS X sucks? I still don't
see the difference being _that_ big, but whatever..
- OS X "mmap()" performance really really sucks.
We do end up doing a _log_ of small mmaps in the "Resolving .." stage.
On Linux, the strace looks like
write(2, "Resolving 316071 deltas.\n", 25) = 25
mmap(NULL, 2619, PROT_READ, MAP_PRIVATE, 3, 0x4c000) = 0x2aaf13be2000
munmap(0x2aaf13be2000, 2619) = 0
mmap(NULL, 2848, PROT_READ, MAP_PRIVATE, 3, 0x4c000) = 0x2aaf13be2000
munmap(0x2aaf13be2000, 2848) = 0
mmap(NULL, 2988, PROT_READ, MAP_PRIVATE, 3, 0x4c000) = 0x2aaf13be2000
munmap(0x2aaf13be2000, 2988) = 0
write(2, " 0% (2/316071) done\r", 22) = 22
mmap(NULL, 3336, PROT_READ, MAP_PRIVATE, 3, 0x4c000) = 0x2aaf13be2000
munmap(0x2aaf13be2000, 3336) = 0
mmap(NULL, 3471, PROT_READ, MAP_PRIVATE, 3, 0x4c000) = 0x2aaf13be2000
munmap(0x2aaf13be2000, 3471) = 0
mmap(NULL, 3611, PROT_READ, MAP_PRIVATE, 3, 0x4c000) = 0x2aaf13be2000
munmap(0x2aaf13be2000, 3611) = 0
...
and it's entirely possible that mmap() really does suck *ss on OS X.
Those small mmap's go on for a _loong_ time.
I've heard of other operations being slow on OS X - and two orders of
magnitude really isn't unthinkable. I don't think people always seem to
really understand how _good_ Linux is, and how much faster it can be. It's
not just "Windows XP" sucks. Quite often it's literally "Linux is just
damn fast".
Sadly, that causes problems when the main developers don't even see any
issues, just because the Linux kernel environment makes things look really
really cheap. Even when it isn't always cheap on other platforms.
Nico - have you looked at perhaps making the index-pack.c "mmap()" usage
do chunking? Or just mmap the whole damn thing once? Linux is fast, but
even Linux will be faster if you just mmap it once ;)
^ permalink raw reply
* Re: [PATCH] Adjust t5510 to put remotes in config
From: Junio C Hamano @ 2006-12-18 23:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <7vr6uwvmk8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Mon, 18 Dec 2006, Johannes Schindelin wrote:
>>
>>> I don't install templates. Ever. I want to be sure that nothing slips in
>>> by mistake, and so I install hooks manually.
>>
>> Side note: prior to installing the tests would fail anyway, no?
>
> They shouldn't. At least the intent was to make the tests read
> from $SRCDIR/templates/blt/ as the source of templates.
>
> But maybe you spotted a bug in t/test-lib.sh; I don't know
> without digging.
Indeed it appears to be the case. I am thinking about applying
this patch to fix it.
-- >8 --
fix testsuite: make sure they use templates freshly built from the source
The initial t/trash repository for testing was created properly
but over time we gained many tests that create secondary test
repositories with init-db or clone and they were not careful
enough.
This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/t/test-lib.sh b/t/test-lib.sh
index ac7be76..7e91497 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -182,6 +182,16 @@ test_create_repo () {
cd "$owd"
}
+# Many tests do init-db and clone but they must be told about the freshly
+# built templates.
+git_init_db () {
+ git init-db --template="$GIT_EXEC_PATH/templates/blt/" "$@"
+}
+
+git_clone () {
+ git clone --template="$GIT_EXEC_PATH/templates/blt/" "$@"
+}
+
test_done () {
trap - exit
case "$test_failure" in
diff --git a/t/t4116-apply-reverse.sh b/t/t4116-apply-reverse.sh
index 74f5c2a..a79c77a 100755
--- a/t/t4116-apply-reverse.sh
+++ b/t/t4116-apply-reverse.sh
@@ -50,12 +50,12 @@ test_expect_success 'setup separate repository lacking postimage' '
git tar-tree initial initial | tar xf - &&
(
- cd initial && git init-db && git add .
+ cd initial && git_init_db && git add .
) &&
git tar-tree second second | tar xf - &&
(
- cd second && git init-db && git add .
+ cd second && git_init_db && git add .
)
'
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
index de45ac4..8a8152b 100755
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -44,7 +44,7 @@ test_expect_success \
'unpack without delta' \
"GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
- git-init-db &&
+ git_init_db &&
git-unpack-objects -n <test-1-${packname_1}.pack &&
git-unpack-objects <test-1-${packname_1}.pack"
@@ -75,7 +75,7 @@ test_expect_success \
'unpack with delta' \
'GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
- git-init-db &&
+ git_init_db &&
git-unpack-objects -n <test-2-${packname_2}.pack &&
git-unpack-objects <test-2-${packname_2}.pack'
@@ -100,7 +100,7 @@ test_expect_success \
'use packed objects' \
'GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
- git-init-db &&
+ git_init_db &&
cp test-1-${packname_1}.pack test-1-${packname_1}.idx .git2/objects/pack && {
git-diff-tree --root -p $commit &&
while read object
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 28744b3..901da8c 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -24,7 +24,7 @@ test_expect_success setup '
parent=$commit || return 1
done &&
git-update-ref HEAD "$commit" &&
- git-clone -l ./. victim &&
+ git_clone -l ./. victim &&
cd victim &&
git-log &&
cd .. &&
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index f7625a6..61e2a55 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -97,7 +97,7 @@ pull_to_client () {
(
mkdir client &&
cd client &&
- git-init-db 2>> log2.txt
+ git_init_db 2>> log2.txt
)
add A1
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index a11ab0a..e2e8c89 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -15,12 +15,12 @@ test_expect_success setup '
git commit -a -m original'
test_expect_success "clone and setup child repos" '
- git clone . one &&
+ git_clone . one &&
cd one &&
echo >file updated by one &&
git commit -a -m "updated by one" &&
cd .. &&
- git clone . two &&
+ git_clone . two &&
cd two &&
git repo-config branch.master.remote one &&
{
@@ -28,7 +28,7 @@ test_expect_success "clone and setup child repos" '
echo "Pull: refs/heads/master:refs/heads/one"
} >.git/remotes/one
cd .. &&
- git clone . three &&
+ git_clone . three &&
cd three &&
git repo-config branch.master.remote two &&
git repo-config branch.master.merge refs/heads/one &&
@@ -74,7 +74,7 @@ test_expect_success 'fetch following tags' '
mkdir four &&
cd four &&
- git init-db &&
+ git_init_db &&
git fetch .. :track &&
git show-ref --verify refs/tags/anno &&
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index f841574..66ef92f 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -17,7 +17,7 @@ test_expect_success setup '
test_expect_success 'pulling into void' '
mkdir cloned &&
cd cloned &&
- git init-db &&
+ git_init_db &&
git pull ..
'
diff --git a/t/t5600-clone-fail-cleanup.sh b/t/t5600-clone-fail-cleanup.sh
index 041be04..1913a12 100755
--- a/t/t5600-clone-fail-cleanup.sh
+++ b/t/t5600-clone-fail-cleanup.sh
@@ -13,7 +13,7 @@ remove the directory before attempting a clone again.'
test_expect_failure \
'clone of non-existent source should fail' \
- 'git-clone foo bar'
+ 'git_clone foo bar'
test_expect_failure \
'failed clone should not leave a directory' \
@@ -29,11 +29,11 @@ test_create_repo foo
# current path not to the target dir
test_expect_failure \
'clone of non-existent (relative to $PWD) source should fail' \
- 'git-clone ../foo baz'
+ 'git_clone ../foo baz'
test_expect_success \
'clone should work now that source exists' \
- 'git-clone foo bar'
+ 'git_clone foo bar'
test_expect_success \
'successfull clone must leave the directory' \
diff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh
index dd9caad..52dab2d 100755
--- a/t/t5700-clone-reference.sh
+++ b/t/t5700-clone-reference.sh
@@ -17,7 +17,7 @@ git commit -m initial'
cd "$base_dir"
test_expect_success 'preparing second repository' \
-'git clone A B && cd B &&
+'git_clone A B && cd B &&
echo second > file2 &&
git add file2 &&
git commit -m addition &&
@@ -27,7 +27,7 @@ git prune'
cd "$base_dir"
test_expect_success 'cloning with reference' \
-'git clone -l -s --reference B A C'
+'git_clone -l -s --reference B A C'
cd "$base_dir"
diff --git a/t/t5710-info-alternate.sh b/t/t5710-info-alternate.sh
index b9f6d96..3c43554 100755
--- a/t/t5710-info-alternate.sh
+++ b/t/t5710-info-alternate.sh
@@ -34,7 +34,7 @@ git prune'
cd "$base_dir"
test_expect_success 'preparing second repository' \
-'git clone -l -s A B && cd B &&
+'git_clone -l -s A B && cd B &&
echo "foo bar" > file2 &&
git add file2 &&
git commit -m "next commit" file2 &&
@@ -44,7 +44,7 @@ git prune'
cd "$base_dir"
test_expect_success 'preparing third repository' \
-'git clone -l -s B C && cd C &&
+'git_clone -l -s B C && cd C &&
echo "Goodbye, cruel world" > file3 &&
git add file3 &&
git commit -m "one more" file3 &&
@@ -54,11 +54,11 @@ git prune'
cd "$base_dir"
test_expect_failure 'creating too deep nesting' \
-'git clone -l -s C D &&
-git clone -l -s D E &&
-git clone -l -s E F &&
-git clone -l -s F G &&
-git clone -l -s G H &&
+'git_clone -l -s C D &&
+git_clone -l -s D E &&
+git_clone -l -s E F &&
+git_clone -l -s F G &&
+git_clone -l -s G H &&
cd H &&
test_valid_repo'
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index 2f4ff82..ae597e8 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -88,7 +88,7 @@ test_expect_success \
test_expect_success "Michael Cassar's test case" '
rm -fr .git papers partA &&
- git init-db &&
+ git_init_db &&
mkdir -p papers/unsorted papers/all-papers partA &&
echo a > papers/unsorted/Thesis.pdf &&
echo b > partA/outline.txt &&
@@ -109,7 +109,7 @@ rm -fr papers partA path?
test_expect_success "Sergey Vlasov's test case" '
rm -fr .git &&
- git init-db &&
+ git_init_db &&
mkdir ab &&
date >ab.c &&
date >ab/d &&
^ permalink raw reply related
* Re: [PATCH] make git a bit less cryptic on fetch errors
From: Andy Parkins @ 2006-12-18 23:22 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0612181505320.18171@xanadu.home>
On Monday 2006, December 18 20:16, Nicolas Pitre wrote:
> - die("unexpected EOF");
> + die("for some reason the remote end hung up unexpectedly");
If we don't know the reason; then saying this makes it sound like we just
couldn't be bothered to write the message. How about just:
"The remote end hung up unexpectedly"
?
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: [PATCH] Small optimizations to gitweb
From: Jakub Narebski @ 2006-12-18 23:17 UTC (permalink / raw)
To: git
In-Reply-To: <20061218224327.GG16029@localhost>
Robert Fitzsimons wrote:
> Limit some of the git_cmd's so they only return the number of lines
> that will be processed.
[...]
> @@ -2876,8 +2879,8 @@ sub git_summary {
> }
> }
>
> - open my $fd, "-|", git_cmd(), "rev-list", "--max-count=17",
> - git_get_head_hash($project), "--"
> + open my $fd, "-|", git_cmd(), "rev-list", "--max-count=16",
> + $head, "--"
> or die_error(undef, "Open git-rev-list failed");
> my @revlist = map { chomp; $_ } <$fd>;
> close $fd;
Actually, that is needed to implement checking if we have more than
the number of commits to show to add '...' at the end only if there
are some commits which we don't show. The same for heads and tags.
(On my short TODO list, but feel free to do it yourself, if you want).
So ack without the last chunk.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox