* Re: git-rebase eats empty commits
From: Michael J Gruber @ 2008-07-14 15:01 UTC (permalink / raw)
To: git
In-Reply-To: <20080712221207.GB22323@leksak.fem-net>
Stephan Beyer venit, vidit, dixit 13.07.2008 00:12:
> Hi,
>
> Michael J Gruber wrote:
>> "git commit" allows empty commits with the "--allow-empty" option, i.e.
>> commits which introduce no change at all. This is sometimes useful for
>> keeping a log of untracked work related to tracked content.
>>
>> "git rebase" removes empty commits, for the good reason that rebasing
>> may make certain commits obsolete; but I don't want that in the case
>> mentioned above. Is there any way to specify "--preserve-empty" or
>> similar?
>
> First I can speak for git-sequencer: there is no such thing as a
> "preserve empty" option, but currently, when you are picking a commit
> that has already been applied so that no changes occur, it will pause.
> (It will not pause if it is a fast-forward.)
> Yet, I was unsure if this is a "correct" behavior, but it seemed to be
> useful, because you can inspect the situation.
>
> In my mind, the same should happen with an empty commit, so I tested it:
> 1. It pauses.
> 2. In that pause I only need to run "git commit --allow-empty" and I have
> the picked empty patch with that commit message.
>
> So if this behavior is kept, there is no such need for such an option.
>
> Now I'm checking it with the old rebase-i (I'm always referring to
> git-rebase--interactive as rebase-i) and exactly the same behavior
> occurs.
>
> But rebase is not rebase-i.
> So I've also checked both, pure rebase and rebase-m: then the empty commit
> is lost.
>
> To sum up, use rebase -i and when it's pausing, do "git commit --allow-empty"
> and then "git rebase --continue" and you have what you want.
I assume this is with git from master? With git 1.5.6.2 rebase -i
doesn't stop there, not even when I change "pick" to "edit"!
So, I guess for now I'll use my hacked git-rebase ("-m", I didn't hack
git-format-patch), maybe 1.6.0 will behave as described above. Anyway
thanks for the hint about distinguishing between rebase and rebase -i.
Michael
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Linus Torvalds @ 2008-07-14 14:51 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Shawn O. Pearce, Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080714065018.GB26446@atjola.homenet>
On Mon, 14 Jul 2008, Björn Steinbrink wrote:
> >
> > Seems that gvfs comes with a completion script that deliberately drops
> > the : from COMP_WORDBREAKS. Do you have that installed Linus?
>
> Ah crap, I should have mentioned which file I'm talking about... It's
> /etc/profile.d/gvfs-bash-completion.sh
Yup. Part of gvfs-0.2.5-1.fc9.x86_64 for me.
Linus
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Linus Torvalds @ 2008-07-14 14:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080714062755.GA15992@spearce.org>
On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>
> What is $COMP_WORDBREAKS set to in your shell? In mine it
> appears to be:
>
> " \"'@><=;|&(:"
>
> which is the I believe the shell default.
Ahhah. Indeed. I don't have the ':'.
> Though we could try to detect : in there and if it is not present
> use the workaround you posted. But I wonder if just asking the
> user to include : is easier.
Umm, if so, git should just set it in the completion script, no?
And doing a google for 'COMP_WORDBREAKS' and 'colon', I don't think I'm
the only one with it unset. In fact, I'm pretty sure I didn't unset it
myself, because I've never heard of that thing. So I think it's a generic
Fedora 9 thing.
(I just checked - that seems to pan out. All the machines with F9 on it I
have access to are missing the ':' - including machines I have not set up
myself like master.kernel.org)
Linus
^ permalink raw reply
* Re: [RFH] Finding all commits that touch the same files as a specific commit
From: Sverre Rabbelier @ 2008-07-14 14:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0807141311520.8950@racer>
On Mon, Jul 14, 2008 at 2:13 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> IMO following the file renames/code moves precisely is really worth the
> time it takes to calculate. Otherwise, the statistics will not reflect
> what was going on in the project, right?
Ah, I did not mean to imply that it is not worth the time it takes to
calculate, more that I do not know how to implement it that way. Of
course if someone has the time/motivation to do so I would very much
make use of it, but I do not have time to do so myself (at least not
until after GSoC). I can have GitStats just ignore the subtree merge
cases (and say that it is not beyond the scope of my project to take
such into account) and have a working program by the end of GSoC. But
if I spend time on getting this to work instead I might end up with a
program that does follow sub-tree merges but is only half-done, and as
such probably won't receive a "OK" grade. So, yes, I would very much
like to see this, but no time to look into doing so myself until after
GSoC.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Johannes Schindelin @ 2008-07-14 12:58 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jakub Narebski, Shawn O. Pearce, Nicolas Pitre, Junio C Hamano,
git, Stephan Hennig
In-Reply-To: <487B4BD8.5030208@op5.se>
Hi,
On Mon, 14 Jul 2008, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 14 Jul 2008, Andreas Ericsson wrote:
> >
> > > Sorry for being clueless here, but why does the older versions need
> > > to be kept in-memory anyway? Aren't we applying the delta each time
> > > we find one, repeatedly creating a new base-object in-memory for
> > > each delta? If we aren't doing that, why do we need more than just
> > > a small amount of memory just for keeping the delta?
> >
> > Think of a delta chain of 49 delta objects, 1 base object. Now reconstruct
> > all of the objects.
> >
> > If you do it one by one, not storing the intermediate results, you end up
> > applying 1 delta for the first, 2 for the second (first the first, then the
> > second), and so on, in total 1 + 2 + 3 + ... + 49 = 49 * 50 / 2 = 1225
> > times.
> >
> > Compare that to the 49 times when reusing the intermediate results.
> >
>
> [...]
>
> while (pop_delta(patch_stack))
> apply_delta(base_object, delta);
>
> where "apply_delta" replaces the base_object->blob with the delta
> applied, releasing the previously used memory?
Delta chains are not (necessarily) independent.
Ciao,
Dscho
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Johannes Schindelin @ 2008-07-14 12:56 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <20080714124109.25414.qmail@06d015ec9c6744.315fe32.mid.smarden.org>
Hi,
On Mon, 14 Jul 2008, Gerrit Pape wrote:
> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > I'm saying this because I believe the best conservative upper bound for
> > > backwards compatibility is Git version in Debian stable. It gets
> > > probably the most stale from all the widely used software distributions
> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
> > > fails miserably on the new packs.
> >
> > Can't we just hit Debian's Git maintainer with a clue bat or a bus,
>
> Please don't. It wouldn't help, rather the opposite I think, espacially
> the bus.
Heh. It was a feeble attempt at humor production ;-)
> We don't introduce new upstream versions into a Debian stable release,
> there's a great effort done for each stable release to reach high
> quality integration of all the software packages available in Debian.
> Once that status is reached, only security fixes and criticial usability
> fixes are added.
If that is the case, we might need to think about fixing that segmentation
fault to 1.4.4.5... Which would be a minor pain in the donkey, I guess.
> The freeze of the packages for the next stable release is planned a few
> days from now, so it looks like Debian 'lenny' will include git 1.5.6.x.
>From my memories of IRC, it seems that quite a few people do not even
consider upgrading.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Andreas Ericsson @ 2008-07-14 12:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Shawn O. Pearce, Nicolas Pitre, Junio C Hamano,
git, Stephan Hennig
In-Reply-To: <alpine.DEB.1.00.0807141322140.8950@racer>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 14 Jul 2008, Andreas Ericsson wrote:
>
>> Sorry for being clueless here, but why does the older versions need
>> to be kept in-memory anyway? Aren't we applying the delta each time
>> we find one, repeatedly creating a new base-object in-memory for
>> each delta? If we aren't doing that, why do we need more than just
>> a small amount of memory just for keeping the delta?
>
> Think of a delta chain of 49 delta objects, 1 base object. Now
> reconstruct all of the objects.
>
> If you do it one by one, not storing the intermediate results, you end up
> applying 1 delta for the first, 2 for the second (first the first, then
> the second), and so on, in total 1 + 2 + 3 + ... + 49 = 49 * 50 / 2 = 1225
> times.
>
> Compare that to the 49 times when reusing the intermediate results.
>
That's only true if you discard the result of applying D1 to DB though.
What I'm wondering is; Why isn't it done like this (pseudo-code):
while (delta = find_earlier_delta(sha1)) {
if (is_base_object(delta)) {
base_object = delta;
break;
}
push_delta(delta, patch_stack);
}
while (pop_delta(patch_stack))
apply_delta(base_object, delta);
where "apply_delta" replaces the base_object->blob with the delta
applied, releasing the previously used memory?
That way, you'll never use more memory than the largest ever size
of the object + 1 delta at a time and still not apply the delta
more than delta_chain_length-1 times.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Petr Baudis @ 2008-07-14 12:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807141256310.8950@racer>
Hi,
On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> On Mon, 14 Jul 2008, Petr Baudis wrote:
>
> > I'm saying this because I believe the best conservative upper bound for
> > backwards compatibility is Git version in Debian stable. It gets
> > probably the most stale from all the widely used software distributions
> > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
> > fails miserably on the new packs.
>
> Can't we just hit Debian's Git maintainer with a clue bat or a bus,
> whichever is easier, and force them to upgrade _in_ Etch? It's not like
> we haven't had _several_ stable releases in-between.
the whole point of having a stable distribution is that random version
upgrades don't happen under your hands; sure, 1.4.4.4 can have plenty of
bugs, but it's buggy in a well-defined way, which is better than upgrade
to newer stable version, which may be less buggy, but in a different
way; also, by upgrading to newer version you might find various subtle
compatibility issues, etc.
Upgrading to newer version, *especially* if it's over then 1.4 - 1.5
boundary, is not something you could seriously expect Debian to do.
At least I actually _hope_ so, as a sysadmin of a network of 40 etch
workstations.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Andreas Ericsson @ 2008-07-14 12:39 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Shawn O. Pearce, Linus Torvalds, Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080714065018.GB26446@atjola.homenet>
Björn Steinbrink wrote:
> On 2008.07.14 08:47:19 +0200, Björn Steinbrink wrote:
>> On 2008.07.14 06:27:55 +0000, Shawn O. Pearce wrote:
>>> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>>>>>> Does it fix this one too:
>>>>>>
>>>>>> git show origin/pu:Makef<tab>
>>>>>>
>>>>>> which totally screws up and becomes
>>>>>>
>>>>>> git show Makefile
>>>>>>
>>>>>> dropping the version specifier?
>>> What is $COMP_WORDBREAKS set to in your shell? In mine it
>>> appears to be:
>>>
>>> " \"'@><=;|&(:"
>>>
>>> which is the I believe the shell default.
>>>
>>> Björn Steinbrink (doener on #git) is running bash 3.2.39 from
>>> Debian and has the same setting, and the completion works correctly
>>> there too. He reports that removing : from COMP_WORDBREAKS will
>>> get the behavior you are reporting as broken.
>>>
>>> I have to say, this sounds to me like you (or some package on your
>>> system) modified COMP_WORDBREAKS away from the default that other
>>> distributions use and that is what is breaking us here. Since we
>>> can have only one setting for this variable in the shell I do not
>>> thing it would be a good idea for our completion package to force
>>> a specific setting upon the user.
>> Seems that gvfs comes with a completion script that deliberately drops
>> the : from COMP_WORDBREAKS. Do you have that installed Linus?
>
> Ah crap, I should have mentioned which file I'm talking about... It's
> /etc/profile.d/gvfs-bash-completion.sh
>
I have that file, and I'm seeing the same issue as Linus.
E13 at http://tiswww.case.edu/php/chet/bash/FAQ mentions it, but
doesn't (imo) give a strong reason why it drops colon from
COMP_WORDBREAKS, as filenames with colons in them aren't exactly
common.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Gerrit Pape @ 2008-07-14 12:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807141256310.8950@racer>
On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> On Mon, 14 Jul 2008, Petr Baudis wrote:
> > I'm saying this because I believe the best conservative upper bound for
> > backwards compatibility is Git version in Debian stable. It gets
> > probably the most stale from all the widely used software distributions
> > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
> > fails miserably on the new packs.
>
> Can't we just hit Debian's Git maintainer with a clue bat or a bus,
Please don't. It wouldn't help, rather the opposite I think, espacially
the bus. We don't introduce new upstream versions into a Debian stable
release, there's a great effort done for each stable release to reach
high quality integration of all the software packages available in
Debian. Once that status is reached, only security fixes and criticial
usability fixes are added.
The freeze of the packages for the next stable release is planned a few
days from now, so it looks like Debian 'lenny' will include git 1.5.6.x.
Regards, Gerrit.
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Johannes Schindelin @ 2008-07-14 12:25 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jakub Narebski, Shawn O. Pearce, Nicolas Pitre, Junio C Hamano,
git, Stephan Hennig
In-Reply-To: <487B439F.8040902@op5.se>
Hi,
On Mon, 14 Jul 2008, Andreas Ericsson wrote:
> Sorry for being clueless here, but why does the older versions need
> to be kept in-memory anyway? Aren't we applying the delta each time
> we find one, repeatedly creating a new base-object in-memory for
> each delta? If we aren't doing that, why do we need more than just
> a small amount of memory just for keeping the delta?
Think of a delta chain of 49 delta objects, 1 base object. Now
reconstruct all of the objects.
If you do it one by one, not storing the intermediate results, you end up
applying 1 delta for the first, 2 for the second (first the first, then
the second), and so on, in total 1 + 2 + 3 + ... + 49 = 49 * 50 / 2 = 1225
times.
Compare that to the 49 times when reusing the intermediate results.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation
From: Johannes Schindelin @ 2008-07-14 12:20 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Steffen Prohaska, git
In-Reply-To: <1216018557.487af87d7bd28@webmail.eunet.at>
Hi,
On Mon, 14 Jul 2008, Johannes Sixt wrote:
> Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Sun, 13 Jul 2008, Johannes Sixt wrote:
> >
> > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> > > *path)
> > > }
> > > }
> > >
> > > -void setup_path(const char *cmd_path)
> > > +void setup_path(void)
> >
> > It seems to me that this patch would not do anything different, but
> > with less code change, if setup_path() would set argv0_path, and not a
> > new function was introduced.
>
> This is just to play a safe game. I had it that way, but I decided to have
> the call to the new git_set_argv0_path() early in git.c because the call
> to setup_path() in git.c is very late, and it could happen that we call
> system_path() (which needs argv0_path) before that. Although I didn't audit
> the code whether this really happens.
Well, okay... I would have rather seen it not change (since there was no
bug to fix), or as a separate patch, but it's Junio's call.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Andreas Ericsson @ 2008-07-14 12:16 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johannes Schindelin, Shawn O. Pearce, Nicolas Pitre,
Junio C Hamano, git, Stephan Hennig
In-Reply-To: <m31w1wu1hc.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>
>>> The only other alternative I can come up with is to change pack-objects
>>> (or at least its defaults) so we don't generate these massive delta
>>> chains. But there are already packs in the wild that use these chains,
>>> resulting in performance problems for clients.
>> But the long chains make the pack actually as efficient as it is...
>
> Perhaps Shawn thought here about limiting delta chain not by its
> *length*, but by its *size* (as required when unpacking last object
> in a delta chanin).
>
> What do you think about this idea?
Sorry for being clueless here, but why does the older versions need
to be kept in-memory anyway? Aren't we applying the delta each time
we find one, repeatedly creating a new base-object in-memory for
each delta? If we aren't doing that, why do we need more than just
a small amount of memory just for keeping the delta?
Feel free to tell me to go away if I'm being stupid. I'm just
curious and probably won't be able to hack up any patches anyway.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFH] Finding all commits that touch the same files as a specific commit
From: Johannes Schindelin @ 2008-07-14 12:13 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git Mailinglist
In-Reply-To: <bd6139dc0807140417h7c9cd309g7cf911e78e7f78c5@mail.gmail.com>
Hi,
On Mon, 14 Jul 2008, Sverre Rabbelier wrote:
> For the activity metric I think pretending that all files with the same
> name or renamed versions of those would make sense, which is what
> appending the new name would do. The downside is that all files with the
> same name get grouped together, I'm not sure which is the lesser of two
> evils. Leaving out information, or (possibly) including too much.
IMO following the file renames/code moves precisely is really worth the
time it takes to calculate. Otherwise, the statistics will not reflect
what was going on in the project, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Johannes Schindelin @ 2008-07-14 12:10 UTC (permalink / raw)
To: Jakub Narebski
Cc: Shawn O. Pearce, Nicolas Pitre, Junio C Hamano, git,
Stephan Hennig, Andreas Ericsson
In-Reply-To: <m31w1wu1hc.fsf@localhost.localdomain>
Hi,
On Mon, 14 Jul 2008, Jakub Narebski wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>
> > > The only other alternative I can come up with is to change pack-objects
> > > (or at least its defaults) so we don't generate these massive delta
> > > chains. But there are already packs in the wild that use these chains,
> > > resulting in performance problems for clients.
> >
> > But the long chains make the pack actually as efficient as it is...
>
> Perhaps Shawn thought here about limiting delta chain not by its
> *length*, but by its *size* (as required when unpacking last object
> in a delta chanin).
So you mean once the sizes of the reconstructed objects are too big, i.e.
when the delta chain is actually _most useful_, we should not do it?
Don't think so.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add testcase for merge.log
From: Miklos Vajna @ 2008-07-14 12:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1215678742-14042-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On Thu, Jul 10, 2008 at 10:32:22AM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Thu, Jul 10, 2008 at 12:50:59AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > The command forgot the configuration variable when rewritten in C.
>
> Thanks. Here is a testcase.
As far as I see this has been forgotten. Should I resend it on top of
current mv/merge-in-c?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Johannes Schindelin @ 2008-07-14 11:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20080714085555.GJ32184@machine.or.cz>
Hi,
On Mon, 14 Jul 2008, Petr Baudis wrote:
> I'm saying this because I believe the best conservative upper bound for
> backwards compatibility is Git version in Debian stable. It gets
> probably the most stale from all the widely used software distributions
> using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
> fails miserably on the new packs.
Can't we just hit Debian's Git maintainer with a clue bat or a bus,
whichever is easier, and force them to upgrade _in_ Etch? It's not like
we haven't had _several_ stable releases in-between.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix reduce_heads
From: Miklos Vajna @ 2008-07-14 11:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Hvammen Johansen, Junio C Hamano, git
In-Reply-To: <20080714114453.GL10347@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 245 bytes --]
On Mon, Jul 14, 2008 at 01:44:53PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> I'll go out tomorrow, so I can send that it today. Sorry for not sending
> a proper patch for the first time. ;-)
Ah, It's already in 'pu', so never mind.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Jakub Narebski @ 2008-07-14 11:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Nicolas Pitre, Junio C Hamano, git,
Stephan Hennig, Andreas Ericsson
In-Reply-To: <alpine.LSU.1.00.0807141216390.32392@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> > The only other alternative I can come up with is to change pack-objects
> > (or at least its defaults) so we don't generate these massive delta
> > chains. But there are already packs in the wild that use these chains,
> > resulting in performance problems for clients.
>
> But the long chains make the pack actually as efficient as it is...
Perhaps Shawn thought here about limiting delta chain not by its
*length*, but by its *size* (as required when unpacking last object
in a delta chanin).
What do you think about this idea?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-14 11:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzetjbif.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 13 Jul 2008, Junio C Hamano wrote:
> * js/more-win (Sun Jul 13 22:31:23 2008 +0200) 6 commits
> - Allow add_path() to add non-existent directories to the path
> - Allow the built-in exec path to be relative to the command
> invocation path
> - Fix relative built-in paths to be relative to the command
> invocation
> + help (Windows): Display HTML in default browser using Windows'
> shell API
> + help.c: Add support for htmldir relative to git_exec_path()
> + Move code interpreting path relative to exec-dir to new function
> system_path()
>
> The earlier parts are obvious; Dscho seemed to have some comments on the
> later ones that are in 'pu'.
Just one, and it seems that the next patch patched that ;-) Not really a
showstopper.
> * mv/merge-in-c (Sun Jul 13 08:13:55 2008 +0000) 19 commits
> + reduce_heads(): thinkofix
Hmm. My earlier response to Sverre was based on an old "next", it seems.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix reduce_heads
From: Miklos Vajna @ 2008-07-14 11:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Hvammen Johansen, Junio C Hamano, git
In-Reply-To: <alpine.LSU.1.00.0807141128240.3486@wbgn129.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
On Mon, Jul 14, 2008 at 11:30:24AM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Unfortunately, Miklos is on holiday this week, so he cannot send a mail of
> his own. Junio, could you fake a commit message with a sign-off for
> Miklos, or do you want me to do it?
I'll go out tomorrow, so I can send that it today. Sorry for not sending
a proper patch for the first time. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Johannes Schindelin @ 2008-07-14 11:44 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Nicolas Pitre, Junio C Hamano, git, Stephan Hennig,
Andreas Ericsson
In-Reply-To: <20080714031242.GA14542@spearce.org>
Hi,
On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Sun, 13 Jul 2008, Shawn O. Pearce wrote:
> >
> > > This should resolve the obscene memory usage of index-pack when
> > > resolving deltas for very large files.
> >
> > I don't like this. Not your patch, but rather the direction this whole
> > thing took in the first place, and now we have to bolt extra complexity
> > on top.
> >
> > I have the feeling this is not the best approach, especially since many
> > long delta chains are going deep and all those intermediate objects are
> > simply useless once the _only_ delta child has been resolved and
> > therefore could be freed right away instead.
>
> I thought about trying to free a base object if this is the last
> resolve_delta() call which would require that data, but I realized this
> is just a "tail-call optimization" and doesn't work in the more general
> case.
However, for cases like Stephan's I assume this is the rule. If you
think of it, most use cases for such a big blob are one-user,
append-only.
> The only other alternative I can come up with is to change pack-objects
> (or at least its defaults) so we don't generate these massive delta
> chains. But there are already packs in the wild that use these chains,
> resulting in performance problems for clients.
But the long chains make the pack actually as efficient as it is...
Ciao,
Dscho
^ permalink raw reply
* Re: [RFH] Finding all commits that touch the same files as a specific commit
From: Sverre Rabbelier @ 2008-07-14 11:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0807131929200.8950@racer>
On Sun, Jul 13, 2008 at 8:30 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Sun, 13 Jul 2008, Sverre Rabbelier wrote:
>> On Sun, Jul 13, 2008 at 3:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> > The data structure the revision traversal machinery uses does not support
>> > this "path-per-commit" natively.
>>
>> Would it be possible to go for a slightly less complicated approach
>> and instead of passing replacing the tracked file, append it?
>
> Maybe I miss something, but do you not have to keep track of the file
> names, in order to keep track of the proper statistics?
Hmm, no, this is just to get commits that touched a (set of) file(s).
I use it to limit the commits I have to check when searching for
reverts.
> If that is the case, appending does not cut it.
For the activity metric I think pretending that all files with the
same name or renamed versions of those would make sense, which is what
appending the new name would do. The downside is that all files with
the same name get grouped together, I'm not sure which is the lesser
of two evils. Leaving out information, or (possibly) including too
much.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 3/4] index-pack: Track the object_entry that creates each base_data
From: Johannes Schindelin @ 2008-07-14 10:15 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, git, Stephan Hennig, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <1216001267-33235-4-git-send-email-spearce@spearce.org>
Hi,
On Sun, 13 Jul 2008, Shawn O. Pearce wrote:
> This however means we must add the missing baes object to the end
> of our packfile prior to calling resolve_delta() on each of the
> dependent deltas. Adding the base first ensures we can read the
> base back from the pack we indexing, as if it had been included by
> the remote side.
s/baes/base/
Otherwise very clear.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix reduce_heads
From: Johannes Schindelin @ 2008-07-14 9:30 UTC (permalink / raw)
To: Sverre Hvammen Johansen; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <402c10cd0807132107s29c470f7hb834bd5c00ef399e@mail.gmail.com>
Hi,
On Sun, 13 Jul 2008, Sverre Hvammen Johansen wrote:
> Reduce_heads used by build in merge failed to find the correct
> heads in cases where duplicate heads are specified.
I liked Junio's explanation better.
> This should fix the last breakage I found. ([PATCH/Test] Build in
> merge is broken)
> I have squashed in Miklos's fix and the two tests cases to protect this.
I'd rather not have it squashed in. Miklos is a GSoC student, and at the
end I want to show the shortlog to tell Google how he fared.
Unfortunately, Miklos is on holiday this week, so he cannot send a mail of
his own. Junio, could you fake a commit message with a sign-off for
Miklos, or do you want me to do it?
Ciao,
Dscho
^ 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