* Re: [RFC] A unique way to express "all" (vs "add vs "update") ?
From: Jerome Lovy @ 2006-12-18 14:04 UTC (permalink / raw)
To: git
In-Reply-To: <87mz5o4v2v.wl%cworth@cworth.org>
Carl Worth wrote:
> On Fri, 15 Dec 2006 12:38:51 +0100, Jerome Lovy wrote:
>> While I am very happy with the refactorings undertaken with regard to
>> "git add/git commit" (both for UI and documentation), I am still a
>> little confused by the different ways I seem to find to express the idea
>> "I want to add (sort of) all file contents".
>
> I agree that there have been huge improvements---particularly in
> documentation. So thanks to everybody!
>
> Here's a simpler idea that might add the unification you're looking
> for. How about a new option:
>
> git add -a|--all
>
> This would allow "git commit -a|--all" to be understood as a simple
> helper for:
>
> git add -a|--all
> git commit
>
> That kind of unification seems like it could be helpful while learning
> things.
Exactly. I like it.
Now, it underlines the fact that this "--all" should IMHO rather be
called "--all-known" or the like - both for "add" and "commit" - but all
the same, I would be very happy with a more complete "git add" following
your proposed unification.
Jérôme
^ permalink raw reply
* Re: [PATCH 2/2] Protect commits recorded in reflog from pruning.
From: Shawn Pearce @ 2006-12-18 14:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6uxzgjb.fsf@assigned-by-dhcp.cox.net>
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.
--
^ permalink raw reply
* Re: Can git be tweaked to work cross-platform, on FAT32?
From: Juergen Ruehle @ 2006-12-18 14:19 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Stefano Spinucci, Martin Langhoff, Florian v. Savigny, git
In-Reply-To: <Pine.LNX.4.63.0612181435100.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin writes:
> On Mon, 18 Dec 2006, Stefano Spinucci wrote:
> > On 12/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > I am sure that there are more problems with it. BTW the problem stems from
> > > Windows having _no_ equivalent to fork().
> >
> > if you are sure that there are more problems with using MMAP, shouldn't
> > NO_MMAP be commented better in the Makefile and in INSTALL, pointing out
> > to use it always on cygwin ???
>
> I argued for that a long time ago, but there were a couple "works-for-me"s
> and I just shut up.
It would be nice to have test cases documenting known failures. Then
people could decide whether these cases are important for their work,
since I don't think it's actually possible to loose data this way.
Personally I've been unsuccessful in trying to recreate failures, but
that is probably just an indication of my inability to use git
correctly:-)
^ permalink raw reply
* [PATCH] Add --remotes option to show-branch
From: Brian Gernhardt @ 2006-12-18 14:53 UTC (permalink / raw)
To: git
We had --heads for refs/heads and --tags for refs/tags, but no easy
way to specify refs/remotes, which is going to be more common now that
it's the default layout for clone.
Also add remotes to --all and update documentation.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
Another patch in my "features I wasted time looking for" series.
I figure that patches are more useful than feature requests, and
that seems to be proven by the fact my patches are getting applied.
This is my first serious foray into git's C code. I simply copied
append_head_ref to get append_remote_ref, since the goal was similar.
If there are additional checks that would need to be done in there,
feel free to fix it, or tell me what I should look for.
As a side note, there's no documentation for the --topics option for
show-branch. If I figure out what it does, I'll write it, but I'd bet
someone else already knows and would love to help a neophite git coder
figure it out. ;-)
Documentation/git-show-branch.txt | 18 +++++++++---------
builtin-show-branch.c | 31 ++++++++++++++++++++++++++-----
2 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index a2445a4..25136b0 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -8,9 +8,9 @@ git-show-branch - Show branches and their commits
SYNOPSIS
--------
[verse]
-'git-show-branch' [--all] [--heads] [--tags] [--topo-order] [--current]
+'git-show-branch' [--all] [--heads] [--remotes] [--tags] [--topo-order]
[--more=<n> | --list | --independent | --merge-base]
- [--no-name | --sha1-name] [<rev> | <glob>]...
+ [--current] [--no-name | --sha1-name] [<rev> | <glob>]...
DESCRIPTION
-----------
@@ -37,14 +37,9 @@ OPTIONS
branches under $GIT_DIR/refs/heads/topic, giving
`topic/*` would show all of them.
---all --heads --tags::
+--all --heads --remotes --tags::
Show all refs under $GIT_DIR/refs, $GIT_DIR/refs/heads,
- and $GIT_DIR/refs/tags, respectively.
-
---current::
- With this option, the command includes the current
- branch to the list of revs to be shown when it is not
- given on the command line.
+ $GIT_DIR/refs/remotes, and $GIT_DIR/refs/tags, respectively.
--topo-order::
By default, the branches and their commits are shown in
@@ -77,6 +72,11 @@ OPTIONS
Among the <reference>s given, display only the ones that
cannot be reached from any other <reference>.
+--current::
+ With this option, the command includes the current
+ branch to the list of revs to be shown when it is not
+ given on the command line.
+
--no-name::
Do not show naming strings for each commit.
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index fb1a400..91251f9 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -6,7 +6,7 @@
#include "builtin.h"
static const char show_branch_usage[] =
-"git-show-branch [--sparse] [--current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [<refs>...]";
+"git-show-branch [--sparse] [--current] [--all] [--heads] [--remotes] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [<refs>...]";
static int default_num;
static int default_alloc;
@@ -383,6 +383,20 @@ static int append_head_ref(const char *refname, const unsigned char *sha1, int f
return append_ref(refname + ofs, sha1, flag, cb_data);
}
+static int append_remote_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ unsigned char tmp[20];
+ int ofs = 13;
+ if (strncmp(refname, "refs/remotes/", ofs))
+ return 0;
+ /* If both remotes/_/foo and tags/foo exists, get_sha1 would
+ * get confused.
+ */
+ if (get_sha1(refname + ofs, tmp) || hashcmp(tmp, sha1))
+ ofs = 5;
+ return append_ref(refname + ofs, sha1, flag, cb_data);
+}
+
static int append_tag_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
if (strncmp(refname, "refs/tags/", 10))
@@ -423,13 +437,18 @@ static int append_matching_ref(const char *refname, const unsigned char *sha1, i
return append_ref(refname, sha1, flag, cb_data);
}
-static void snarf_refs(int head, int tag)
+static void snarf_refs(int head, int tag, int remote)
{
if (head) {
int orig_cnt = ref_name_cnt;
for_each_ref(append_head_ref, NULL);
sort_ref_range(orig_cnt, ref_name_cnt);
}
+ if (remote) {
+ int orig_cnt = ref_name_cnt;
+ for_each_ref(append_remote_ref, NULL);
+ sort_ref_range(orig_cnt, ref_name_cnt);
+ }
if (tag) {
int orig_cnt = ref_name_cnt;
for_each_ref(append_tag_ref, NULL);
@@ -554,7 +573,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
struct commit_list *list = NULL, *seen = NULL;
unsigned int rev_mask[MAX_REVS];
int num_rev, i, extra = 0;
- int all_heads = 0, all_tags = 0;
+ int all_heads = 0, all_tags = 0, all_remotes;
int all_mask, all_revs;
int lifo = 1;
char head[128];
@@ -586,9 +605,11 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
break;
}
else if (!strcmp(arg, "--all"))
- all_heads = all_tags = 1;
+ all_heads = all_remotes = all_tags = 1;
else if (!strcmp(arg, "--heads"))
all_heads = 1;
+ else if (!strcmp(arg, "--remotes"))
+ all_remotes = 1;
else if (!strcmp(arg, "--tags"))
all_tags = 1;
else if (!strcmp(arg, "--more"))
@@ -630,7 +651,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
all_heads = 1;
if (all_heads + all_tags)
- snarf_refs(all_heads, all_tags);
+ snarf_refs(all_heads, all_tags, all_remotes);
while (0 < ac) {
append_one_rev(*av);
ac--; av++;
--
1.4.4.1.GIT
^ permalink raw reply related
* clarification on "racy-git" & very fast change+commit
From: David Tweed @ 2006-12-18 15:30 UTC (permalink / raw)
To: git
Hi, I'm getting prepared to do a trial migration my "selected files chronological database"
(think plan9's venti but not on every single file) to git and I'd just like to check something.
I'm still don't understand lots of stuff about git but I've read "racy-git.txt" in
Documentation for git-1.4.4.2. It appears to be saying that there used to be a race (involving
1-second timestamp limitations of filesystems) but now
things are done with a slow path fallback for would-race situations so that there is no race in
any operations any more? If the race is there, the file suggests it isn't a problem
for commiting?
I'm just checking because the way I'm planning to migrate is by using a script to
loop, checking out each snapshot from my existing backup system and commit it into git. I've got
quite a fast PC with a reasonable amount of memory but using ext3 as filesystem (which
still has 1 second timestamp resolution AIUI),
so it seems entirely plausible that I could get checkouts which alter only a few files
taking much, much less than a second. I don't know if any of them also happen to
have the same filesize, if they do this pattern seems more likely to meet the condtions of the
"race" than natural, normal git usage, so I want to see if I need to think about this dealing
with this issue. My understanding from racy-git.txt is that I don't.
Many thanks for any insight,
cheers, dave tweed
___________________________________________________________
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal
^ permalink raw reply
* [PATCH] Add documentation for show-branch --topics
From: Brian Gernhardt @ 2006-12-18 15:48 UTC (permalink / raw)
To: git
Add a quick paragraph explaining the --topics option for show-branch.
The explanation is an abbreviated version of the commit message from
d320a5437f8304cf9ea3ee1898e49d643e005738.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
git blame helped me find the original description of this feature.
I'm not sure this is the best explanation possible, but it gives
both a quick description and a way to figure out what it's doing.
Which is hopefully better than nothing.
Documentation/git-show-branch.txt | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index a2445a4..a9a0e0c 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git-show-branch' [--all] [--heads] [--tags] [--topo-order] [--current]
[--more=<n> | --list | --independent | --merge-base]
- [--no-name | --sha1-name] [<rev> | <glob>]...
+ [--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
DESCRIPTION
-----------
@@ -86,6 +86,14 @@ OPTIONS
of "master"), name them with the unique prefix of their
object names.
+--topics::
+ Shows only commits that are NOT on the first branch given.
+ This helps track topic branches by hiding any commit that
+ is already in the main line of development. When given
+ "git show-branch --topics master topic1 topic2", this
+ will show the revisions given by "git rev-list ^master
+ topic1 topic2"
+
Note that --more, --list, --independent and --merge-base options
are mutually exclusive.
--
1.4.4.1.GIT
^ permalink raw reply related
* Re: [PATCH] fetch-pack: avoid fixing thin packs when unnecessary
From: Johannes Schindelin @ 2006-12-18 21:55 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612181638220.18171@xanadu.home>
Hi,
On Mon, 18 Dec 2006, Nicolas Pitre wrote:
> On Mon, 18 Dec 2006, Johannes Schindelin wrote:
>
> >
> > When we know that there are no common commits, the pack must be
> > closed (i.e. non-thin) already. Avoid "fixing" it in that case.
> >
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> >
> > ---
> >
> > On Mon, 18 Dec 2006, Johannes Schindelin wrote:
> >
> > > On Mon, 18 Dec 2006, Randal L. Schwartz wrote:
> > >
> > > > But then it took nearly an *hour* at the next phase:
> > > >
> > > > Resolving 313037 deltas.
> > > > 100% (313037/313037) done
> > >
> > > Ouch.
> > >
> > > We try to avoid unpacking the thin packs received by git-fetch.
> > > This means completing that pack (since it can contain deltas
> > > against objects which are part of another pack).
> > >
> > > However, for the clone this is utter overkill. We really should
> > > try to avoid resolving unnecessarily. This is really for the
> > > clone case, since we do not have _any_ objects in the local
> > > repository.
> > >
> > > It happens that the other case -- fetching an independent branch
> > > -- is easy enough: we already have the check for it in
> > > fetch-pack.c:586.
> >
> > ... and here is a lightly tested fix.
>
> NAK.
>
> This fixes nothing. See previous message.
You're completely right. My patch does what I say, but it does not fix the
problem.
Ciao,
Dscho
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Randal L. Schwartz @ 2006-12-18 22:01 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0612181625140.18171@xanadu.home>
>>>>> "Nicolas" == Nicolas Pitre <nico@cam.org> writes:
Nicolas> Could you try the following please:
Nicolas> time git-index-pack -v -o /dev/null .git/objects/pack/*.pack
Nicolas> and provide us with the time it took (or an estimate if it is going to
Nicolas> be on hour long)?
Nicolas> Performing the above on my kernel repository (after it was repacked into
Nicolas> a single ~150MB pack) takes only 37 seconds.
I have a single pack.
"Indexing" took about 30 seconds.
"Resolving 313037 deltas" looks like it's going to take an hour.
So that *was* a local delay.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-18 22:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612181012280.3479@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 17 Dec 2006, Junio C Hamano wrote:
>>
>> - blame A..B's output shows lines attributed to the boundary
>> commit with commit SHA-1 prefixed with '^';
>
> I wonder if it would make sense to have a flag or mode or something where
> boundary commit attributions are simply left unattributed (ie just leave
> that _empty_).
How about this?
-- >8 --
blame: -b (blame.blankboundary) and --root (blame.showroot)
When blame.blankboundary is set (or -b option is given), commit
object names are blanked out in the "human readable" output
format for boundary commits.
When blame.showroot is not set (or --root is not given), the
root commits are treated as boundary commits. The code still
attributes the lines to them, but with -b their object names are
not shown.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-blame.c | 33 +++++++++++++++++++++++++++++++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index a250724..211bdb3 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -22,7 +22,9 @@
static char blame_usage[] =
"git-blame [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>] [-M] [-C] [-C] [commit] [--] file\n"
" -c, --compatibility Use the same output mode as git-annotate (Default: off)\n"
+" -b Show blank SHA-1 for boundary commits (Default: off)\n"
" -l, --long Show long commit SHA1 (Default: off)\n"
+" --root Do not treat root commits as boundaries (Default: off)\n"
" -t, --time Show raw timestamp (Default: off)\n"
" -f, --show-name Show original filename (Default: auto)\n"
" -n, --show-number Show original linenumber (Default: off)\n"
@@ -36,6 +38,8 @@ static int longest_author;
static int max_orig_digits;
static int max_digits;
static int max_score_digits;
+static int show_root;
+static int blank_boundary;
#ifndef DEBUG
#define DEBUG 0
@@ -1095,6 +1099,9 @@ static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt)
if (commit->object.parsed)
mark_parents_uninteresting(commit);
}
+ /* treat root commit as boundary */
+ if (!commit->parents && !show_root)
+ commit->object.flags |= UNINTERESTING;
/* Take responsibility for the remaining entries */
for (ent = sb->ent; ent; ent = ent->next)
@@ -1318,8 +1325,12 @@ static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
int length = (opt & OUTPUT_LONG_OBJECT_NAME) ? 40 : 8;
if (suspect->commit->object.flags & UNINTERESTING) {
- length--;
- putchar('^');
+ if (!blank_boundary) {
+ length--;
+ putchar('^');
+ }
+ else
+ memset(hex, ' ', length);
}
printf("%.*s", length, hex);
@@ -1639,6 +1650,19 @@ static void prepare_blame_range(struct scoreboard *sb,
usage(blame_usage);
}
+static int git_blame_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "blame.showroot")) {
+ show_root = git_config_bool(var, value);
+ return 0;
+ }
+ if (!strcmp(var, "blame.blankboundary")) {
+ blank_boundary = git_config_bool(var, value);
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
int cmd_blame(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
@@ -1654,6 +1678,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
char type[10];
const char *bottomtop = NULL;
+ git_config(git_blame_config);
save_commit_buffer = 0;
opt = 0;
@@ -1662,6 +1687,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
const char *arg = argv[i];
if (*arg != '-')
break;
+ else if (!strcmp("-b", arg))
+ blank_boundary = 1;
+ else if (!strcmp("--root", arg))
+ show_root = 1;
else if (!strcmp("-c", arg))
output_option |= OUTPUT_ANNOTATE_COMPAT;
else if (!strcmp("-t", arg))
^ permalink raw reply related
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Nicolas Pitre @ 2006-12-18 22:09 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Linus Torvalds, git
In-Reply-To: <86hcvs984c.fsf@blue.stonehenge.com>
On Mon, 18 Dec 2006, Randal L. Schwartz wrote:
> >>>>> "Nicolas" == Nicolas Pitre <nico@cam.org> writes:
>
> Nicolas> Could you try the following please:
>
> Nicolas> time git-index-pack -v -o /dev/null .git/objects/pack/*.pack
>
> Nicolas> and provide us with the time it took (or an estimate if it is going to
> Nicolas> be on hour long)?
>
> Nicolas> Performing the above on my kernel repository (after it was repacked into
> Nicolas> a single ~150MB pack) takes only 37 seconds.
>
> I have a single pack.
>
> "Indexing" took about 30 seconds.
> "Resolving 313037 deltas" looks like it's going to take an hour.
>
> So that *was* a local delay.
What CPU and amount of ram do you have?
Are you on Windows?
^ permalink raw reply
* Re: [PATCH] fetch-pack: avoid fixing thin packs when unnecessary
From: Nicolas Pitre @ 2006-12-18 22:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.63.0612182251210.19693@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 18 Dec 2006, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 18 Dec 2006, Nicolas Pitre wrote:
>
> > On Mon, 18 Dec 2006, Johannes Schindelin wrote:
> >
> > > ... and here is a lightly tested fix.
> >
> > NAK.
> >
> > This fixes nothing. See previous message.
>
> You're completely right. My patch does what I say, but it does not fix the
> problem.
Your patch is also unnecessary. For use_thin_pack to be true, you must
provide --thin to git-fetch-pack which is not the case when cloning.
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Randal L. Schwartz @ 2006-12-18 22:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0612181708340.18171@xanadu.home>
>>>>> "Nicolas" == Nicolas Pitre <nico@cam.org> writes:
>> "Indexing" took about 30 seconds.
>> "Resolving 313037 deltas" looks like it's going to take an hour.
>>
>> So that *was* a local delay.
Nicolas> What CPU and amount of ram do you have?
2.2 Ghz Intel Core 2 Duo (Macbook Pro high end)
I can compile and install GNU Emacs from source in 11 minutes. :)
Nicolas> Are you on Windows?
Gawd no!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Linus Torvalds @ 2006-12-18 22:22 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Nicolas Pitre, git
In-Reply-To: <86hcvs984c.fsf@blue.stonehenge.com>
On Mon, 18 Dec 2006, Randal L. Schwartz wrote:
>
> I have a single pack.
>
> "Indexing" took about 30 seconds.
> "Resolving 313037 deltas" looks like it's going to take an hour.
>
> So that *was* a local delay.
Ok, interesting. Two questions:
- what does "top" say (is it CPU-bound? Is it perhaps blowing out your
disk cache? Is it swapping?)
- do you have "oprofile" (or even just pgprof) to see where the *hell*
that time is spent, if it's actually CPU?
For me, it takes 25 seconds. Not an hour:
[torvalds@woody linux]$ time git-index-pack -v -o /dev/null .git/objects/pack/*.pack
Indexing 393507 objects.
100% (393507/393507) done
Resolving 316071 deltas.
100% (316071/316071) done
fatal: unable to create /dev/null: File exists
real 0m24.619s
user 0m22.569s
sys 0m1.316s
(I admit that 25 seconds is already "too much", but it does actually end
up exploding a lot of objects and doing quite a bit of work, so I guess
it's fair).
And the process grew to 33MB in RSS at it's biggest, so it wasn't even
using all that much memory (33MB isn't _tiny_, but considering that the
pack in question is 155MB and has hundreds of thousands of objects, 33MB
isn't really all that bad.
You're running this under OS X, aren't you? It's a pig of an OS, but
"almost one hour" vs "25 seconds" is still unreasonable.
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Randal L. Schwartz @ 2006-12-18 22:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.64.0612181414200.3479@woody.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
>> So that *was* a local delay.
Linus> Ok, interesting. Two questions:
Linus> - what does "top" say (is it CPU-bound? Is it perhaps blowing out your
Linus> disk cache? Is it swapping?)
Not swapping, but CPU bound.
Linus> - do you have "oprofile" (or even just pgprof) to see where the *hell*
Linus> that time is spent, if it's actually CPU?
I'm a "bear of very little brane" regarding code development on OSX. I
can ask around to see if there's someway to profile this.
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!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: [PATCH] Adjust t5510 to put remotes in config
From: Johannes Schindelin @ 2006-12-18 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iwox59i.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 18 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Since .git/remotes/ is no longer created by default, t5510 failed.
>
> Does not reproduce for me.
I just checked out a fresh copy of 'next'. It still fails. The culprit is
61dde8f91672ab362f3cfd3af8d6d09d448d4ffe, which removes the line
mkdir -p "$GIT_DIR/remotes" &&
which is line 372 in the parent of that commit.
> > While at it, convert the tests to use the config way of specifying
> > remotes instead of creating a file in .git/remotes/.
>
> I think adding tests to use config is good, but I'd rather see
> the test scripts to test not _only_ config but both.
Okay. How about fixing the first hunk as proposed, and the second by
'mkdir .git/remotes'?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Adjust t5510 to put remotes in config
From: Junio C Hamano @ 2006-12-18 22:42 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612182325550.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 18 Dec 2006, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > Since .git/remotes/ is no longer created by default, t5510 failed.
>>
>> Does not reproduce for me.
>
> I just checked out a fresh copy of 'next'. It still fails. The culprit is
> 61dde8f91672ab362f3cfd3af8d6d09d448d4ffe, which removes the line
>
> mkdir -p "$GIT_DIR/remotes" &&
>
> which is line 372 in the parent of that commit.
Hmmmmm.
But git-clone runs git-init-db and we ship an empty remotes
directory still as part of the templates. Why would removal of
that line matter?
^ permalink raw reply
* Re: [PATCH] (Take 3) git-branch: deleting remote branches in new layout
From: Quy Tonthat @ 2006-12-18 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodq11w49.fsf@assigned-by-dhcp.cox.net>
This patch is based on Junio's patch (all errors are my fault, of
course) to provide the following features to 'git-branch -d|-D'
o Option -r can be used with -d or -D to delete "remote" (tracking)
branch(es), for examples,
git branch -d -r origin/man origin/html
this command will delete the named branches in $GIT_DIR/refs/remotes,
according to the new layout.
(No, you can no longer mix "local" and "remote" branches in one
deletion command.)
o If there are more than one branches to be deleted, failure on one will
no longer stop git-branch to process the next ones.
o 'git-branch -d|-D' now returns error code 1 if at least one of
branches deleting is failed. (0 returned for fully success as before)
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
This patch is to replace all my previous patches on this thread.
builtin-branch.c | 88 ++++++++++++++++++++++++++++++++++++++----------------
1 files changed, 62 insertions(+), 26 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 560309c..52b6b5a 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -12,8 +12,12 @@
#include "builtin.h"
static const char builtin_branch_usage[] =
- "git-branch (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | (-m | -M) [<oldbranch>] <newbranch> | [-r | -a] [-v [--abbrev=<length>]]";
+ "git-branch [-r] (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | (-m | -M) [<oldbranch>] <newbranch> | [-r | -a] [-v [--abbrev=<length>]]";
+#define REF_UNKNOWN_TYPE 0x00
+#define REF_LOCAL_BRANCH 0x01
+#define REF_REMOTE_BRANCH 0x02
+#define REF_TAG 0x04
static const char *head;
static unsigned char head_sha1[20];
@@ -89,12 +93,28 @@ static int in_merge_bases(const unsigned char *sha1,
return ret;
}
-static void delete_branches(int argc, const char **argv, int force)
+static int delete_branches(int argc, const char **argv, int force, int kinds)
{
struct commit *rev, *head_rev = head_rev;
unsigned char sha1[20];
- char *name;
+ char *name = NULL;
+ const char *fmt, *remote;
int i;
+ int ret = 0;
+
+ switch (kinds) {
+ case REF_REMOTE_BRANCH:
+ fmt = "refs/remotes/%s";
+ remote = "remote ";
+ force = 1;
+ break;
+ case REF_LOCAL_BRANCH:
+ fmt = "refs/heads/%s";
+ remote = "";
+ break;
+ default:
+ die("cannot use -a with -d");
+ }
if (!force) {
head_rev = lookup_commit_reference(head_sha1);
@@ -102,16 +122,30 @@ static void delete_branches(int argc, const char **argv, int force)
die("Couldn't look up commit object for HEAD");
}
for (i = 0; i < argc; i++) {
- if (!strcmp(head, argv[i]))
- die("Cannot delete the branch you are currently on.");
+ if (kinds == REF_LOCAL_BRANCH && !strcmp(head, argv[i])) {
+ error("Cannot delete the branch '%s' "
+ "which you are currently on.", argv[i]);
+ ret = 1;
+ continue;
+ }
+
+ if (name)
+ free(name);
- name = xstrdup(mkpath("refs/heads/%s", argv[i]));
- if (!resolve_ref(name, sha1, 1, NULL))
- die("Branch '%s' not found.", argv[i]);
+ name = xstrdup(mkpath(fmt, argv[i]));
+ if (!resolve_ref(name, sha1, 1, NULL)) {
+ error("%sbranch '%s' not found.",
+ remote, argv[i]);
+ ret = 1;
+ continue;
+ }
rev = lookup_commit_reference(sha1);
- if (!rev)
- die("Couldn't look up commit object for '%s'", name);
+ if (!rev) {
+ error("Couldn't look up commit object for '%s'", name);
+ ret = 1;
+ continue;
+ }
/* This checks whether the merge bases of branch and
* HEAD contains branch -- which means that the HEAD
@@ -120,26 +154,27 @@ static void delete_branches(int argc, const char **argv, int force)
if (!force &&
!in_merge_bases(sha1, rev, head_rev)) {
- fprintf(stderr,
- "The branch '%s' is not a strict subset of your current HEAD.\n"
- "If you are sure you want to delete it, run 'git branch -D %s'.\n",
+ error("The branch '%s' is not a strict subset of your current HEAD."
+ "If you are sure you want to delete it, run 'git branch -D %s'.",
argv[i], argv[i]);
- exit(1);
+ ret = 1;
+ continue;
}
- if (delete_ref(name, sha1))
- printf("Error deleting branch '%s'\n", argv[i]);
- else
- printf("Deleted branch %s.\n", argv[i]);
+ if (delete_ref(name, sha1)) {
+ error("Error deleting %sbranch '%s'", remote,
+ argv[i]);
+ ret = 1;
+ } else
+ printf("Deleted %sbranch %s.\n", remote, argv[i]);
- free(name);
}
-}
-#define REF_UNKNOWN_TYPE 0x00
-#define REF_LOCAL_BRANCH 0x01
-#define REF_REMOTE_BRANCH 0x02
-#define REF_TAG 0x04
+ if (name)
+ free(name);
+
+ return(ret);
+}
struct ref_item {
char *name;
@@ -357,6 +392,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
int reflog = 0;
int kinds = REF_LOCAL_BRANCH;
int i;
+ int status = 0;
setup_ident();
git_config(git_branch_config);
@@ -435,7 +471,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
head += 11;
if (delete)
- delete_branches(argc - i, argv + i, force_delete);
+ status = delete_branches(argc - i, argv + i, force_delete, kinds);
else if (i == argc)
print_ref_list(kinds, verbose, abbrev);
else if (rename && (i == argc - 1))
@@ -449,5 +485,5 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
else
usage(builtin_branch_usage);
- return 0;
+ return (status);
^ permalink raw reply related
* Re: [PATCH] git-parse-remote: fix ambiguous shell bug in expand_refs_wildcard
From: Jeff King @ 2006-12-18 22:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Herbert Xu, git
In-Reply-To: <7v4prtx9hu.fsf@assigned-by-dhcp.cox.net>
On Mon, Dec 18, 2006 at 11:57:33AM -0800, Junio C Hamano wrote:
> Sounds like a dash bug, if my reading of 2.6.2 Parameter
> Expansion is correct:
>
> http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html
Interestingly, this works in dash:
$ foo=bar}
$ echo ${foo%'}'}
bar
but doing it inside an interpolated string doesn't:
$ foo=bar}
$ echo "${foo%'}'}"
bar}'}
> This would be another way to work it around. Both dash and bash
> say 'foo':
>
> $ suf='^{}'
> $ name='foo^{}'
> $ echo "${name%$suf}"
> foo
>
> I think this might be easier to read than using "^{\}".
That seems reasonable to me.
^ permalink raw reply
* Re: [PATCH] Adjust t5510 to put remotes in config
From: Johannes Schindelin @ 2006-12-18 22:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvek8vnb8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 18 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi,
> >
> > On Mon, 18 Dec 2006, Junio C Hamano wrote:
> >
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >>
> >> > Since .git/remotes/ is no longer created by default, t5510 failed.
> >>
> >> Does not reproduce for me.
> >
> > I just checked out a fresh copy of 'next'. It still fails. The culprit is
> > 61dde8f91672ab362f3cfd3af8d6d09d448d4ffe, which removes the line
> >
> > mkdir -p "$GIT_DIR/remotes" &&
> >
> > which is line 372 in the parent of that commit.
>
> Hmmmmm.
>
> But git-clone runs git-init-db and we ship an empty remotes
> directory still as part of the templates. Why would removal of
> that line matter?
I don't install templates. Ever. I want to be sure that nothing slips in
by mistake, and so I install hooks manually.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Adjust t5510 to put remotes in config
From: Johannes Schindelin @ 2006-12-18 22:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612182346500.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
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?
Ciao,
Dscho
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Nicolas Pitre @ 2006-12-18 22:50 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Linus Torvalds, git
In-Reply-To: <86ac1k975v.fsf@blue.stonehenge.com>
On Mon, 18 Dec 2006, Randal L. Schwartz wrote:
> Nicolas> What CPU and amount of ram do you have?
>
> 2.2 Ghz Intel Core 2 Duo (Macbook Pro high end)
> I can compile and install GNU Emacs from source in 11 minutes. :)
So it shouldn't be a lack of resource.
> Nicolas> Are you on Windows?
>
> Gawd no!
;-)
I asked because it could have had something with the mmap() usage
recently reported to be dreadfully slow on Windows
^ permalink raw reply
* Re: [PATCH] Adjust t5510 to put remotes in config
From: Junio C Hamano @ 2006-12-18 22:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612182349070.19693@wbgn013.biozentrum.uni-wuerzburg.de>
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.
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Martin Langhoff @ 2006-12-18 23:02 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Linus Torvalds, Nicolas Pitre, git
In-Reply-To: <8664c896xv.fsf@blue.stonehenge.com>
On 18 Dec 2006 14:26:36 -0800, Randal L. Schwartz <merlyn@stonehenge.com> 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!
Me too -- but entirely possible. Disk IO is specially painful on OSX.
Stat calls are horrid. Using Arch (which abused stat calls to no end)
many ops would take 50x-100x longer on OSX than on Linux. A large
unpacked repo with git is a real pain -- and packing it can take
hours.
Once you are packed it's sweet, but large repos are a pain to deal
with. You won't impress anyone with performance over a linux kernel
repo -- starting up gitk can take a long time. Stat-heavy stuff like
git-diff is noticeably slower under OSX.
Have you got a linux partition you can boot into to get comparative timings?
[This is part of the reason I am migrating my OSX machine to Linux
fulltime, now that it seems that mergedfb+randr will let me switch to
dual monitors "hot".]
cheers,
^ permalink raw reply
* [PATCH] Small optimizations to gitweb
From: Robert Fitzsimons @ 2006-12-18 22:43 UTC (permalink / raw)
To: git
Limit some of the git_cmd's so they only return the number of lines
that will be processed. Don't recompute head hash or have_snapshot
values.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
gitweb/gitweb.perl | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5ea3fda..1990f15 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1141,6 +1141,7 @@ sub git_get_last_activity {
open($fd, "-|", git_cmd(), 'for-each-ref',
'--format=%(refname) %(committer)',
'--sort=-committerdate',
+ '--count=1',
'refs/heads') or return;
my $most_recent = <$fd>;
close $fd or return;
@@ -2559,6 +2560,8 @@ sub git_shortlog_body {
# uses global variable $project
my ($revlist, $from, $to, $refs, $extra) = @_;
+ my $have_snapshot = gitweb_have_snapshot();
+
$from = 0 unless defined $from;
$to = $#{$revlist} if (!defined $to || $#{$revlist} < $to);
@@ -2586,7 +2589,7 @@ sub git_shortlog_body {
$cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
$cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree");
- if (gitweb_have_snapshot()) {
+ if ($have_snapshot) {
print " | " . $cgi->a({-href => href(action=>"snapshot", hash=>$commit)}, "snapshot");
}
print "</td>\n" .
@@ -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;
--
1.4.4.2.gee60-dirty
^ permalink raw reply related
* 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