* Re: [PATCH 2/2] git reflog expire
From: Shawn Pearce @ 2006-12-19 10:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcvsry2c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Of course that's not what the code does, because if either the
> > old or the new object is no longer in the ODB you are pruning away
> > the log entry. I cannot however come up with a better name than
> > --expire-lost. :-(
>
> How about --expire-unreachable?
That actually does make more sense. Those commits are what we would
traditionally have called unreachable commits, or dangling commits.
Hmm. Flip a coin. I'm probably as bad at UI as you are. :-)
> To have 'expire' action as a subcommand to 'git-reflog' is from
> implementor's point of view, and is a horrible organization from
> the UI standpoint. To the end users, it may be easier to have a
> single 'git-gc' command that runs these commands with reasonable
> set of defaults:
>
> - rerere gc
> - reflog expire --all
> - (possibly) repack -a -d
> - prune
>
> If we go that route, it probably is not even necessary to
> advertise that 'expire' is a subcommand of reflog. The users
> would not run it from the command line; it is an implementation
> detail of 'git-gc' command.
Yes! I agree with you completely here. I'd also include 'pack-refs
--prune' to your list above, at least for refs/tags. Those suckers
can eat up a lot of disk, slow down viualizers, and well, just
don't change. Pack 'em!
> > Needing a subcommand like 'git reflog show HEAD' is just a lot
> > of typing[*1*].
>
> I am very interested in seeing how 'git reflog show HEAD' would
> show the reflog entries. I've tried showing it just like log
> family shows (it is reasonably easy; you build the list of revs
> out of reflog entries and feed them to 'git-show' machinery),
> and while it works, it is unusable for the purpose of seeing
> which ones are the lost ones (amended commits and rebased branch
> remnants).
At this point I'm going to wind up getting less than 4 hours of
sleep tonight (I'll be lucky if I get 3). So I'm just going to skip
trying to draft out what I might want this to look like right now.
I'll try to sketch out a dump by hand from a couple of my own reflogs
and post 'em later tonight. Ugh. Tonight. Its Tuesday already.
My body still thinks its Monday.
> The best I came up with is still my "show-branch --reflog" so
> far. You really need to show not just the commit title but how
> they topologically relate to the commits on the surviving
> branch, and I think having something graphical or semi-graphical
> is a must.
Probably right. But I can't make heads or tails out of that
output for just one topic branch whose reflog consists of only
the following:
$ cut -f2 .git/logs/refs/heads/sp/mapwin
checkout: Created from origin^0
am: Create read_or_die utility routine.
reset --hard 106d710b
am: Create read_or_die utility routine.
reset --hard
rebase: Create read_or_die utility routine.
`show-branch --reflog --topics sp/mapwin` prints much shorter output
and almost says something useful, but not really.
--
^ permalink raw reply
* Re: [PATCH] Only warn about missing branch.<n>.merge in pull.
From: Junio C Hamano @ 2006-12-19 10:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612191127540.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> >> merge = pu for remote second # merge 'pu' if pulling from second
>>
>> 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 ;-).
>
>
> Would
>
> merge = pu, when pulling second
>
> be better? ;-)
The users can work it around by writing:
merge pu remote second for
Just document it clearly and say "if you are going to make an
pentapus (or more) with remote branches that include ones named
'for' and 'remote', do not place them as third and second
(respectively) word from the end on the line" ;-).
Your "noise word" remote is actually useful.
^ permalink raw reply
* Re: git-diff & cg-diff behavior difference
From: Vincent Legoll @ 2006-12-19 10:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90612181249y5ee69a8al28e97a22dca80c81@mail.gmail.com>
On 12/18/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> I'd say that it's a bug that cg-diff doesn't work in a subdir.
> However, there is a much more important difference between cg-diff and
> git-diff: cg-diff is equivalent to git-diff HEAD because cogito hides
> the index from you.
That's what I wanted to know: if it was a deliberate behavior, a bug on
my side, or on git's...
> If you are developing in a (mostly) straight line, and not dealing
> much with merges and rebases, that's a great simplification. If you
> are coming from a different SCM it's probably a good thing too.
That's me and me !
> If/when you want to use git's smarts for merging and rebasing, you'll
> definitely want to know a lot more about the index, and you'll
> probably stop using cogito.
That will be me some times...
> (Actually, even though I know and love the index I use cogito all the
> time, and switch to git commands for merging and rebasing. Works
> great... and yet Linus is in a merge-centric role, so changing the
> defaults to ignore the index most of the time is a bit of a hot issue
That's no problem with me, if behavior is properly documented...
--
^ permalink raw reply
* Re: [PATCH] Only warn about missing branch.<n>.merge in pull.
From: Johannes Schindelin @ 2006-12-19 10:30 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <200612190159.58658.Josef.Weidendorfer@gmx.de>
Hi,
On Tue, 19 Dec 2006, Josef Weidendorfer wrote:
> 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.
Granted. Suggestions?
> I even would remove the need for the word "remote" in the second merge
> line.
No. In Git, a line like
blabla
would turn into a boolean named "blabla" being true.
Ciao,
Dscho
^ permalink raw reply
* Re: A call for better git-rebase messages
From: Junio C Hamano @ 2006-12-19 10:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <em8e32$s7b$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> $ git rebase abort
> mkdir: cannot create directory `.dotest': File exists
>
> It seems that I cannot create a .dotest directory, and I wonder if you
> are in the middle of patch application or another rebase. If that is not
> the case, please rm -fr .dotest and run me again. I am stopping in case
> you still have something valuable there.
>
> Why we do not tell to run "git rebase --abort" here? I think the command
> know that it is a middle of git-rebase, not the middle of git-am...
Does it? At least the original author of the command does not
know if you did this:
$ git am mbox
... ugh, conflicted.
$ git rebase master
^ permalink raw reply
* Re: [PATCH] Only warn about missing branch.<n>.merge in pull.
From: Johannes Schindelin @ 2006-12-19 10:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, Shawn O. Pearce, git
In-Reply-To: <7v7iwovg99.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 18 Dec 2006, Junio C Hamano wrote:
> 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 ;-).
Would
merge = pu, when pulling second
be better? ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitk: pass --no-left-right to rev-list
From: Junio C Hamano @ 2006-12-19 10:28 UTC (permalink / raw)
To: Jeff King; +Cc: Paul Mackerras, git
In-Reply-To: <20061219100534.GA9206@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think there are three fixes:
> 1. this patch (avoid using left-right)
> 2. gitk can detect and parse the new format
> 3. revert automatic use of left-right
> The third makes the most sense to me.
1. has the problem that it requires the version of Porcelains
and the core to be tightly linked. 2. is nice but unnecessary
burden in the short term. 3. does not break things for anybody,
but if left-right output is useful on the terminal, it burdens
the end-user typing from the command line.
So in the longer term, 2 is probably slightly more preferrable,
but my philosophy is "do not change anything unless absolutely
necessary", so 3 is also sensible, at least in the short term.
Thanks for catching this quickly, before it hit the master.
Let's revert 57612319.
^ permalink raw reply
* Re: [PATCH 2/2] git reflog expire
From: Shawn Pearce @ 2006-12-19 10:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcvsry2c.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
> > I'd like to take a stab at the log display code for the reflog
> > command, but I'd also really like to port forward (aka rewrite)
> > that mmap window code I keep saying I'll work on, but never quite
> > seem to do...
>
> After today's pread() thing, I was also wondering about that too
> ;-).
I'm working on it now. I have rather long days on Monday and
Tuesday which keep me otherwise occupied and away from Git work.
Hopefully I'll have something sometime on Wednesday, which so far
I have all day free for hacking.
Smaller mmap units may help on some larger projects. For example
'git whatchanged' shouldn't need to setup page table entries for
the entire pack file when only the front and middle are needed to
obtain the data for the most recent 25 commits, before the user
kills the pager.
But that's just me pulling words out of the air. I'm tired too,
time to catch a few hours of sleep. Probably by the time I get back
to my email our local kernel hackers will tell me how wrong I am.
--
^ permalink raw reply
* Re: [PATCH 2/2] git reflog expire
From: Junio C Hamano @ 2006-12-19 10:15 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061219090851.GH2511@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Of course that's not what the code does, because if either the
> old or the new object is no longer in the ODB you are pruning away
> the log entry. I cannot however come up with a better name than
> --expire-lost. :-(
How about --expire-unreachable?
> I'm thinking that we may want the 'expire' subcommand to simply be
> implied by '--expire' instead.
After coding this, my conclusion is the same as yours, but
reasoning behind it is slightly different.
To have 'expire' action as a subcommand to 'git-reflog' is from
implementor's point of view, and is a horrible organization from
the UI standpoint. To the end users, it may be easier to have a
single 'git-gc' command that runs these commands with reasonable
set of defaults:
- rerere gc
- reflog expire --all
- (possibly) repack -a -d
- prune
If we go that route, it probably is not even necessary to
advertise that 'expire' is a subcommand of reflog. The users
would not run it from the command line; it is an implementation
detail of 'git-gc' command.
> Needing a subcommand like 'git reflog show HEAD' is just a lot
> of typing[*1*].
I am very interested in seeing how 'git reflog show HEAD' would
show the reflog entries. I've tried showing it just like log
family shows (it is reasonably easy; you build the list of revs
out of reflog entries and feed them to 'git-show' machinery),
and while it works, it is unusable for the purpose of seeing
which ones are the lost ones (amended commits and rebased branch
remnants).
The best I came up with is still my "show-branch --reflog" so
far. You really need to show not just the commit title but how
they topologically relate to the commits on the surviving
branch, and I think having something graphical or semi-graphical
is a must.
> I would also say maybe we want to make --dry-run the default, with
> a final message which tells the user that if they really want to
> make it possible to throw away the commits printed above then
> restart the expire operation.
I am moderately negative on that. Nobody does it like that;
prune, branch -d, tag -d,...
> I'd like to take a stab at the log display code for the reflog
> command, but I'd also really like to port forward (aka rewrite)
> that mmap window code I keep saying I'll work on, but never quite
> seem to do...
After today's pread() thing, I was also wondering about that too
;-).
^ permalink raw reply
* A call for better git-rebase messages
From: Jakub Narebski @ 2006-12-19 10:17 UTC (permalink / raw)
To: git
$ git rebase abort
mkdir: cannot create directory `.dotest': File exists
It seems that I cannot create a .dotest directory, and I wonder if you
are in the middle of patch application or another rebase. If that is not
the case, please rm -fr .dotest and run me again. I am stopping in case
you still have something valuable there.
Why we do not tell to run "git rebase --abort" here? I think the command
know that it is a middle of git-rebase, not the middle of git-am...
$ git rebase --onto origin next gitweb/web
Nothing to do.
I'm not sure, but I think gitweb/web which was empty branch based off
former next is now empty branch based off current gitweb, i.e. at least
head of this branch has changed... but I'm not sure because
$ git rebase --abort
is _not_ recorded as such, but as "reset --hard ORIG_HEAD" (I think).
It looks like it is, because after "reset --hard ORIG_HEAD" (which was
result of "git rebase --abort" of "git rebase origin" (I forgot
gitweb/web was based off other branch) there is "reset --hard <sha1>",
and this sha1 is sha1 of both gitweb/web and origin.
I'd rather rebase told me that it did something (moved head), but
there are no patches to be applied.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitk: pass --no-left-right to rev-list
From: Jeff King @ 2006-12-19 10:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
Now that rev-list does left-right marking by default on symmetric
differences, command lines like this:
gitk master...origin
produce an error.
Signed-off-by: Jeff King <peff@peff.net>
---
I think there are three fixes:
1. this patch (avoid using left-right)
2. gitk can detect and parse the new format
3. revert automatic use of left-right
The third makes the most sense to me.
People do use symmetric difference with various porcelains. For example,
I typically carry a few local patches in 'master'. My daily
sit-down-with-git workflow is:
git-fetch
gitk master...origin
git-rebase origin
where the second step gives me a nice graph of what's new and which
patches I'm still carrying.
That means that porcelains which use git-rev-list are _all_ going to
break.
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 3dabc69..ec61a37 100755
--- a/gitk
+++ b/gitk
@@ -33,7 +33,7 @@ proc start_rev_list {view} {
set order "--date-order"
}
if {[catch {
- set fd [open [concat | git rev-list --header $order \
+ set fd [open [concat | git rev-list --no-left-right --header $order \
--parents --boundary --default HEAD $args] r]
} err]} {
puts stderr "Error executing git rev-list: $err"
--
^ permalink raw reply related
* Re: branch rebase and push
From: Jakub Narebski @ 2006-12-19 9:57 UTC (permalink / raw)
To: git
In-Reply-To: <45875EFC.5090408@gmail.com>
SungHyun Nam wrote:
> 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
The problem you have is with _push_, not branch, I think.
Does repository you pull from has rebased branch 'br'? If yes, is it
pulled with + in pull/fetch line? Perhaps (but read documentation first,
please) "git push --force" is what you want, provided that other side
doesn't forbid non fast-forward pushes.
Bu you usually don't rebase published branch (don't change history
of published branch). Equivalently, you don't publish rebased branch
until it is ready (or merged in ;-).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Jeff King @ 2006-12-19 9:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Theodore Tso, Nicolas Pitre,
Randal L. Schwartz, git
In-Reply-To: <7v1wmwtfmk.fsf@assigned-by-dhcp.cox.net>
On Tue, Dec 19, 2006 at 01:10:59AM -0800, Junio C Hamano wrote:
> > in a very unscientific test, without your patch local cloning of the
> > LilyPond repo takes 1m33s (user), and with your patch (pread() instead of
> > mmap()) it takes 1m13s (user). The real times are somewhat bogus, but
> > still in favour of pread(), but only by 8 seconds instead of 20.
> >
> > This is on Linux 2.4.32.
>
> Interesting. Anybody have numbers from 2.6?
Similar results to those posted by Marco Roeland (numbers below are
index-pack of linux-2.6 on 2.6.18 i386 smp):
mmap
46.78user 4.18system 0:51.08elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+725627minor)pagefaults 0swaps
pread
45.70user 3.12system 0:48.96elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+363794minor)pagefaults 0swaps
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Marco Roeland @ 2006-12-19 9:13 UTC (permalink / raw)
To: Shawn Pearce
Cc: Marco Roeland, Linus Torvalds, Theodore Tso, Nicolas Pitre,
Johannes Schindelin, Randal L. Schwartz, git
In-Reply-To: <20061219084908.GG2511@spearce.org>
On Tuesday December 19th 2006 at 03:49 Shawn Pearce wrote:
> [pread patch to speed up git-index-pack on Mac OS X]
>
> More testing on Linux is probably needed, but if using pread()
> on Linux is breakeven or slightly faster (as suggested by Johannes'
> LilyPond test) this 60x performance improvement on initial clone
> of largish projects on Mac OS X would be nice to have.
I see a decrease in total time (so an improvement in performance)
going from 37.3 to 35.2 seconds with the pread patch on Linux x86-64.
Note that both my testing on Linux and Mac OS X was done on dual core
processors (Athlon 3800+ XP on Linux and Intel Core 2 Duo 2.16GHz on an
iMac). Git is only single threaded and thus uses only core, but the
system can use the other core.
The minor page faults also decreased from 734866 to 370690. Nice.
> Not that I personally frequently clone large projects on Mac OS X.
> But new users to Git might. :-)
And perhaps the Cygwin version might benefit too.
--
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Junio C Hamano @ 2006-12-19 9:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Theodore Tso, Nicolas Pitre, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.63.0612190930460.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> in a very unscientific test, without your patch local cloning of the
> LilyPond repo takes 1m33s (user), and with your patch (pread() instead of
> mmap()) it takes 1m13s (user). The real times are somewhat bogus, but
> still in favour of pread(), but only by 8 seconds instead of 20.
>
> This is on Linux 2.4.32.
Interesting. Anybody have numbers from 2.6?
^ permalink raw reply
* Re: [PATCH 2/2] git reflog expire
From: Shawn Pearce @ 2006-12-19 9:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64c8thr4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> This prepares a place to collect reflog management subcommands,
> and implements "expire" action.
>
> $ git reflog expire --dry-run \
> --expire=4.weeks \
> --expire-lost=1.week \
> refs/heads/master
>
> The expiration uses two timestamps: --expire and --expire-lost.
> Entries older than expire time (defaults to 90 days), and
> entries older than expire-lost time (defaults to 30 days) and
> talk about a commit that has been rewound and made unreachable
> from the current tip of the ref are removed from the reflog.
>
> The parameter handling is still rough, but I think the
> core logic for expiration is already sound.
I agree, this looked pretty good to me.
I disagree with the option name '--expire-lost'. The way I
initially read that was:
--expire-lost: ok, if the object was already pruned out of
the ODB and the reflog entry is older than 1 week, remove it;
otherwise keep it in case the user could manually recover the
object from another ODB.
Of course that's not what the code does, because if either the
old or the new object is no longer in the ODB you are pruning away
the log entry. I cannot however come up with a better name than
--expire-lost. :-(
Perhaps --expire-lost should default to just be 1/3 of the time of
--expire, whatever --expire is: 90 day default or command line value?
I'm thinking that we may want the 'expire' subcommand to simply be
implied by '--expire' instead. Basically my rational here is I want
to be able to do 'git reflog HEAD' to view the reflog associated with
my current branch, effectively seeing the Git operational history
of this branch. Or 'git reflog a b' to see the operational history
of two branches with their reflogs interleaved based on entry time.
Needing a subcommand like 'git reflog show HEAD' is just a lot
of typing[*1*].
I would also say maybe we want to make --dry-run the default, with
a final message which tells the user that if they really want to
make it possible to throw away the commits printed above then
restart the expire operation, e.g.:
$ git reflog --expire=4.weeks --expire-lost=1.week master
would expire ...
would expire ...
would expire ...
Restart with '--prune' to expire the above log entries and commits.
$ git reflog --expire=4.weeks --expire-lost=1.week master --prune
?
I'd like to take a stab at the log display code for the reflog
command, but I'd also really like to port forward (aka rewrite)
that mmap window code I keep saying I'll work on, but never quite
seem to do...
*1* Yes, I know, I'll do bash completion for this command too. ;-)
--
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Shawn Pearce @ 2006-12-19 8:49 UTC (permalink / raw)
To: Marco Roeland
Cc: Linus Torvalds, Theodore Tso, Nicolas Pitre, Johannes Schindelin,
Randal L. Schwartz, git
In-Reply-To: <20061219084017.GB30448@fiberbit.xs4all.nl>
Marco Roeland <marco.roeland@xs4all.nl> wrote:
> On Tuesday December 19th 2006 at 03:32 Shawn Pearce wrote:
>
> > > Anyway, try the pread() version first, see if that fixes the OS X problem.
> >
> > It does. Without pread() (aka stock 'next') it takes me over an
> > hour to index a pack of linux-2.6. With pread() its 1m6s to run
> > index-pack on the same pack file. The indexes are (of course)
> > identically produced.
>
> I see the same here. From an (estimated) time of 37 minutes down to 52
> seconds with the pread() patch. Running the profiler (shark) on the old
> version showed that 85% of the time was spent in the Mac OS X mmap()
> system call.
More testing on Linux is probably needed, but if using pread()
on Linux is breakeven or slightly faster (as suggested by Johannes'
LilyPond test) this 60x performance improvement on initial clone
of largish projects on Mac OS X would be nice to have.
Not that I personally frequently clone large projects on Mac OS X.
But new users to Git might. :-)
--
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Marco Roeland @ 2006-12-19 8:40 UTC (permalink / raw)
To: Shawn Pearce
Cc: Linus Torvalds, Theodore Tso, Nicolas Pitre, Randal L. Schwartz,
git
In-Reply-To: <20061219083242.GF2511@spearce.org>
On Tuesday December 19th 2006 at 03:32 Shawn Pearce wrote:
> > Anyway, try the pread() version first, see if that fixes the OS X problem.
>
> It does. Without pread() (aka stock 'next') it takes me over an
> hour to index a pack of linux-2.6. With pread() its 1m6s to run
> index-pack on the same pack file. The indexes are (of course)
> identically produced.
I see the same here. From an (estimated) time of 37 minutes down to 52
seconds with the pread() patch. Running the profiler (shark) on the old
version showed that 85% of the time was spent in the Mac OS X mmap()
system call.
--
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Marco Roeland @ 2006-12-19 7:52 UTC (permalink / raw)
To: Shawn Pearce
Cc: Linus Torvalds, Theodore Tso, Nicolas Pitre, Randal L. Schwartz,
git
In-Reply-To: <20061219072607.GD2511@spearce.org>
On Tuesday December 19th 2006 at 02:26 Shawn Pearce wrote:
> [git-index-pack limping along on Mac OS X]
>
> 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.
A bit off topic but it might help people diagnose and test different
strategies.
The equivalent of "oprofile" on Mac OS X is a tool called "shark" from
Apple itself. It's very nice actually.
It's in the CHUD (Computer Hardware Understanding
Developer Tools) package. More information at
http://developer.apple.com/tools/performance and it is free as in beer.
;-)
Also the OpenSSL version on Mac OS X is rather old and compiled as
32-bit application. OpenSSL is one of the few userspace packages that
_really_ benefits tremendously from being compiled as 64-bit. It might
explain a bit of the enormous performance difference in this case. But
only profiling (perhaps with the help of "shark") will tell of course...
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.
--
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Shawn Pearce @ 2006-12-19 8:32 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.
It does. Without pread() (aka stock 'next') it takes me over an
hour to index a pack of linux-2.6. With pread() its 1m6s to run
index-pack on the same pack file. The indexes are (of course)
identically produced.
--
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Johannes Schindelin @ 2006-12-19 8:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Tso, Nicolas Pitre, Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0612182234260.3479@woody.osdl.org>
Hi,
in a very unscientific test, without your patch local cloning of the
LilyPond repo takes 1m33s (user), and with your patch (pread() instead of
mmap()) it takes 1m13s (user). The real times are somewhat bogus, but
still in favour of pread(), but only by 8 seconds instead of 20.
This is on Linux 2.4.32.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2/2] git reflog expire
From: Junio C Hamano @ 2006-12-19 8:25 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <7vy7p4u1au.fsf@assigned-by-dhcp.cox.net>
This prepares a place to collect reflog management subcommands,
and implements "expire" action.
$ git reflog expire --dry-run \
--expire=4.weeks \
--expire-lost=1.week \
refs/heads/master
The expiration uses two timestamps: --expire and --expire-lost.
Entries older than expire time (defaults to 90 days), and
entries older than expire-lost time (defaults to 30 days) and
talk about a commit that has been rewound and made unreachable
from the current tip of the ref are removed from the reflog.
The parameter handling is still rough, but I think the
core logic for expiration is already sound.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 1 +
builtin-reflog.c | 175 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1 +
git.c | 1 +
4 files changed, 178 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 8919dab..17dabde 100644
--- a/Makefile
+++ b/Makefile
@@ -292,6 +292,7 @@ BUILTIN_OBJS = \
builtin-prune-packed.o \
builtin-push.o \
builtin-read-tree.o \
+ builtin-reflog.o \
builtin-repo-config.o \
builtin-rev-list.o \
builtin-rev-parse.o \
diff --git a/builtin-reflog.c b/builtin-reflog.c
new file mode 100644
index 0000000..aef2fc2
--- /dev/null
+++ b/builtin-reflog.c
@@ -0,0 +1,175 @@
+#include "cache.h"
+#include "builtin.h"
+#include "commit.h"
+#include "refs.h"
+#include "dir.h"
+#include <time.h>
+
+struct expire_reflog_cb {
+ FILE *newlog;
+ const char *ref;
+ struct commit *ref_commit;
+ unsigned long expire_total;
+ unsigned long expire_lost;
+};
+
+static int keep_entry(struct commit **it, unsigned char *sha1)
+{
+ *it = NULL;
+ if (is_null_sha1(sha1))
+ return 1;
+ *it = lookup_commit_reference_gently(sha1, 1);
+ return (*it != NULL);
+}
+
+static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
+ char *data, void *cb_data)
+{
+ struct expire_reflog_cb *cb = cb_data;
+ unsigned long timestamp;
+ char *cp, *ep;
+ struct commit *old, *new;
+
+ cp = strchr(data, '>');
+ if (!cp || *++cp != ' ')
+ goto prune;
+ timestamp = strtoul(cp, &ep, 10);
+ if (*ep != ' ')
+ goto prune;
+ if (timestamp < cb->expire_total)
+ goto prune;
+
+ if (!keep_entry(&old, osha1) || !keep_entry(&new, nsha1))
+ goto prune;
+
+ if ((timestamp < cb->expire_lost) &&
+ ((old && !in_merge_bases(old, cb->ref_commit)) ||
+ (new && !in_merge_bases(new, cb->ref_commit))))
+ goto prune;
+
+ if (cb->newlog)
+ fprintf(cb->newlog, "%s %s %s",
+ sha1_to_hex(osha1), sha1_to_hex(nsha1), data);
+ return 0;
+ prune:
+ if (!cb->newlog)
+ fprintf(stderr, "would prune %s", data);
+ return 0;
+}
+
+struct cmd_reflog_expire_cb {
+ int dry_run;
+ unsigned long expire_total;
+ unsigned long expire_lost;
+};
+
+static int expire_reflog(const char *ref, const unsigned char *sha1, int unused, void *cb_data)
+{
+ struct cmd_reflog_expire_cb *cmd = cb_data;
+ struct expire_reflog_cb cb;
+ struct ref_lock *lock;
+ char *newlog_path = NULL;
+ int status = 0;
+
+ if (strncmp(ref, "refs/", 5))
+ return error("not a ref '%s'", ref);
+
+ memset(&cb, 0, sizeof(cb));
+ /* we take the lock for the ref itself to prevent it from
+ * getting updated.
+ */
+ lock = lock_ref_sha1(ref + 5, sha1);
+ if (!lock)
+ return error("cannot lock ref '%s'", ref);
+ if (!file_exists(lock->log_file))
+ goto finish;
+ if (!cmd->dry_run) {
+ newlog_path = xstrdup(git_path("logs/%s.lock", ref));
+ cb.newlog = fopen(newlog_path, "w");
+ }
+
+ cb.ref_commit = lookup_commit_reference_gently(sha1, 1);
+ if (!cb.ref_commit) {
+ status = error("ref '%s' does not point at a commit", ref);
+ goto finish;
+ }
+ cb.ref = ref;
+ cb.expire_total = cmd->expire_total;
+ cb.expire_lost = cmd->expire_lost;
+ for_each_reflog_ent(ref, expire_reflog_ent, &cb);
+ finish:
+ if (cb.newlog) {
+ if (fclose(cb.newlog))
+ status |= error("%s: %s", strerror(errno),
+ newlog_path);
+ if (rename(newlog_path, lock->log_file)) {
+ status |= error("cannot rename %s to %s",
+ newlog_path, lock->log_file);
+ unlink(newlog_path);
+ }
+ }
+ free(newlog_path);
+ unlock_ref(lock);
+ return status;
+}
+
+static const char reflog_expire_usage[] =
+"git-reflog expire [--dry-run] [--expire=<time>] [--expire-lost=<time>] [--all] <refs>...";
+
+static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
+{
+ struct cmd_reflog_expire_cb cb;
+ unsigned long now = time(NULL);
+ int i, status, do_all;
+
+ save_commit_buffer = 0;
+ do_all = status = 0;
+ memset(&cb, 0, sizeof(cb));
+ cb.expire_total = now - 90 * 24 * 3600;
+ cb.expire_lost = now - 30 * 24 * 3600;
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+ if (!strcmp(arg, "--dry-run") || !strcmp(arg, "-n"))
+ cb.dry_run = 1;
+ else if (!strncmp(arg, "--expire=", 9))
+ cb.expire_total = approxidate(arg + 9);
+ else if (!strncmp(arg, "--expire-lost=", 14))
+ cb.expire_lost = approxidate(arg + 14);
+ else if (!strcmp(arg, "--all"))
+ do_all = 1;
+ else if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ else if (arg[0] == '-')
+ usage(reflog_expire_usage);
+ else
+ break;
+ }
+ if (do_all)
+ status |= for_each_ref(expire_reflog, &cb);
+ while (i < argc) {
+ const char *ref = argv[i++];
+ unsigned char sha1[20];
+ if (!resolve_ref(ref, sha1, 1, NULL)) {
+ status |= error("%s points nowhere!", ref);
+ continue;
+ }
+ status |= expire_reflog(ref, sha1, 0, &cb);
+ }
+ return status;
+}
+
+static const char reflog_usage[] =
+"git-reflog (expire | ...)";
+
+int cmd_reflog(int argc, const char **argv, const char *prefix)
+{
+ if (argc < 2)
+ usage(reflog_usage);
+ else if (!strcmp(argv[1], "expire"))
+ return cmd_reflog_expire(argc - 1, argv + 1, prefix);
+ else
+ usage(reflog_usage);
+}
diff --git a/builtin.h b/builtin.h
index 08519e7..fdc0907 100644
--- a/builtin.h
+++ b/builtin.h
@@ -51,6 +51,7 @@ extern int cmd_prune(int argc, const char **argv, const char *prefix);
extern int cmd_prune_packed(int argc, const char **argv, const char *prefix);
extern int cmd_push(int argc, const char **argv, const char *prefix);
extern int cmd_read_tree(int argc, const char **argv, const char *prefix);
+extern int cmd_reflog(int argc, const char **argv, const char *prefix);
extern int cmd_repo_config(int argc, const char **argv, const char *prefix);
extern int cmd_rev_list(int argc, const char **argv, const char *prefix);
extern int cmd_rev_parse(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 016ee8a..ae4c99f 100644
--- a/git.c
+++ b/git.c
@@ -256,6 +256,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
{ "prune-packed", cmd_prune_packed, RUN_SETUP },
{ "push", cmd_push, RUN_SETUP },
{ "read-tree", cmd_read_tree, RUN_SETUP },
+ { "reflog", cmd_reflog, RUN_SETUP },
{ "repo-config", cmd_repo_config },
{ "rev-list", cmd_rev_list, RUN_SETUP },
{ "rev-parse", cmd_rev_parse, RUN_SETUP },
--
1.4.4.2.g688739
^ permalink raw reply related
* [PATCH 1/2] Move in_merge_bases() to commit.c
From: Junio C Hamano @ 2006-12-19 8:25 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <7vy7p4u1au.fsf@assigned-by-dhcp.cox.net>
This reasonably useful function was hidden inside builtin-branch.c
---
* This is used by the next one, which is why this is part of
the 'reflog entry and pruning' series.
builtin-branch.c | 21 +--------------------
commit.c | 17 +++++++++++++++++
commit.h | 1 +
3 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 560309c..12eebc0 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -70,25 +70,6 @@ const char *branch_get_color(enum color_branch ix)
return "";
}
-static int in_merge_bases(const unsigned char *sha1,
- struct commit *rev1,
- struct commit *rev2)
-{
- struct commit_list *bases, *b;
- int ret = 0;
-
- bases = get_merge_bases(rev1, rev2, 1);
- for (b = bases; b; b = b->next) {
- if (!hashcmp(sha1, b->item->object.sha1)) {
- ret = 1;
- break;
- }
- }
-
- free_commit_list(bases);
- return ret;
-}
-
static void delete_branches(int argc, const char **argv, int force)
{
struct commit *rev, *head_rev = head_rev;
@@ -119,7 +100,7 @@ static void delete_branches(int argc, const char **argv, int force)
*/
if (!force &&
- !in_merge_bases(sha1, rev, head_rev)) {
+ !in_merge_bases(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",
diff --git a/commit.c b/commit.c
index a6d543e..4bddcbe 100644
--- a/commit.c
+++ b/commit.c
@@ -1009,3 +1009,20 @@ struct commit_list *get_merge_bases(struct commit *one,
free(rslt);
return result;
}
+
+int in_merge_bases(struct commit *rev1, struct commit *rev2)
+{
+ struct commit_list *bases, *b;
+ int ret = 0;
+
+ bases = get_merge_bases(rev1, rev2, 1);
+ for (b = bases; b; b = b->next) {
+ if (!hashcmp(rev1->object.sha1, b->item->object.sha1)) {
+ ret = 1;
+ break;
+ }
+ }
+
+ free_commit_list(bases);
+ return ret;
+}
diff --git a/commit.h b/commit.h
index fc13de9..10eea9f 100644
--- a/commit.h
+++ b/commit.h
@@ -107,4 +107,5 @@ int read_graft_file(const char *graft_file);
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup);
+int in_merge_bases(struct commit *rev1, struct commit *rev2);
#endif /* COMMIT_H */
--
1.4.4.2.g688739
^ permalink raw reply related
* Re: [PATCH] Adjust t5510 to put remotes in config
From: Johannes Schindelin @ 2006-12-19 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virg8vl74.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 18 Dec 2006, Junio C Hamano wrote:
> fix testsuite: make sure they use templates freshly built from the source
Okay.
But why not introduce the environment variable GIT_TEMPLATE_DIR, to
imitate similar solutions. This would result in a smaller diff, and people
would not have to remember typing "git_init_db" in tests (I admit, I did
not spot the subtle difference right away, and thought they were
white-space fixes...).
I.e. something like this instead:
--
[PATCH] Introduce GIT_TEMPLATE_DIR
Instead of passing --template explicitely to init-db and clone, you can
just set the environment variable GIT_TEMPLATE_DIR.
Also make use of it in the tests, to make sure that the templates are
copied.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-init-db.c | 7 +++++--
t/test-lib.sh | 3 ++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index fa70baa..85cd4d9 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -124,8 +124,11 @@ static void copy_templates(const char *git_dir, int len, const char *template_di
int template_len;
DIR *dir;
- if (!template_dir)
- template_dir = DEFAULT_GIT_TEMPLATE_DIR;
+ if (!template_dir) {
+ template_dir = getenv("GIT_TEMPLATE_DIR");
+ if (!template_dir)
+ template_dir = DEFAULT_GIT_TEMPLATE_DIR;
+ }
strcpy(template_path, template_dir);
template_len = strlen(template_path);
if (template_path[template_len-1] != '/') {
diff --git a/t/test-lib.sh b/t/test-lib.sh
index ac7be76..f0f9cd6 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -208,8 +208,9 @@ test_done () {
# t/ subdirectory and are run in trash subdirectory.
PATH=$(pwd)/..:$PATH
GIT_EXEC_PATH=$(pwd)/..
+GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
HOME=$(pwd)/trash
-export PATH GIT_EXEC_PATH HOME
+export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR HOME
GITPERLLIB=$(pwd)/../perl/blib/lib:$(pwd)/../perl/blib/arch/auto/Git
^ permalink raw reply related
* 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
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