* Re: git diff - no newline after @@ ?
From: Petr Sebor @ 2006-08-18 13:19 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, git
In-Reply-To: <20060818124428.GA22328@sigio.intra.peff.net>
Jeff King wrote:
> Try diff -p to get a hunk comment.
>
> -Peff
>
Ouch.... got it. Is there a way to turn the comment generation off btw?
Sorry for the noise...
Petr
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Johannes Schindelin @ 2006-08-18 13:36 UTC (permalink / raw)
To: Jon Smirl; +Cc: Nicolas Pitre, Shawn Pearce, git
In-Reply-To: <9e4733910608180615q4895334bw57c55e59a4ac5482@mail.gmail.com>
Hi,
On Fri, 18 Aug 2006, Jon Smirl wrote:
> I suspect the size reduction is directly proportional to the age of
> the repository. The kernel repository only has three years worth of
> data in it. Linus has the full history in another repository that is
> not in general distribution. We can get it from him when he gets back
> from vacation.
Maybe you mean
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/tglx/history.git
Ciao,
Dscho
^ permalink raw reply
* Re: git diff - no newline after @@ ?
From: Jakub Narebski @ 2006-08-18 13:42 UTC (permalink / raw)
To: git
In-Reply-To: <44E5BE60.5010901@scssoft.com>
Petr Sebor wrote:
> Jeff King wrote:
>> Try diff -p to get a hunk comment.
>>
>> -Peff
>>
>
> Ouch.... got it. Is there a way to turn the comment generation off btw?
Other than GIT_DIFF_OPTS (although how to turn off present -p option), or
GIT_EXTERNAL_DIFF (see git-diff-tree(1))?
Why do you want to turn it off? patch understands this format...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Jon Smirl @ 2006-08-18 13:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.63.0608181536250.28360@wbgn013.biozentrum.uni-wuerzburg.de>
On 8/18/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 18 Aug 2006, Jon Smirl wrote:
>
> > I suspect the size reduction is directly proportional to the age of
> > the repository. The kernel repository only has three years worth of
> > data in it. Linus has the full history in another repository that is
> > not in general distribution. We can get it from him when he gets back
> > from vacation.
>
> Maybe you mean
>
> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/tglx/history.git
That one only goes to 2002, the full one goes back to around 1990.
>
> Ciao,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] gitweb: use action dispatcher for non-project actions, too.
From: Carl Worth @ 2006-08-18 14:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Martin Waitz, git
In-Reply-To: <20060818131656.GR13776@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]
On Fri, 18 Aug 2006 15:16:57 +0200, Petr Baudis wrote:
>
> Dear diary, on Thu, Aug 17, 2006 at 05:00:11PM CEST, I got a letter
> where Carl Worth <cworth@cworth.org> said that...
> > PS. A secondary problem is the difficulty of publishing a new
> > branch. But if I can get the 3 URLs above down to 1, then I could
> > probably live with the user having to figure out how to combine the
> > repository URL with the branch name, (in different ways depending on
> > what the user is doing).
>
> Could you be more specific here, please? Is it just that Git won't
> automagically pick up new branches published on the server?
The best I've been able to come up with is:
See my new branch <branch> at <URL>
Then it's up to the user to do one of the following (depending on what
they want):
1. For gitweb, either:
a. Browse to <URL> and manually find <branch> in the list (ugh!)
b. Manually construct a branch-specific URL: <URL>;h=<branch>
2. For git fetch/clone:
Construct a command line looking something like this:
git fetch <URL> <branch>:tracking-branch
and optionally do some manual editing of a config file if they want
to easily get at this branch again in the future.
And that assumes I can give out a single <URL> in the first place, of
course.
Beyond that, here are some of the things I would like:
* A single thingy I could publish for <URL> and <branch>. Ideally this
would have no whitespace in it and would be directly
cut-and-paste-able for use in either gitweb or the git command-line.
* A mechanism for not requiring me to invent tracking-branch names. I
end up manually doing a scheme with short prefixes for any given
repository. It would be nice if I could configure that (in
.git/remotes/<something> say) once so that any new branch I pulled
would get its properly named tracking branch. And git could find the
right remotes file by matching up the URL.
* An easy way, (maybe a one-letter command-line option), for stashing
a branch I'm fetching off into .git/remotes/<something> where again,
it would find the right file by matching the URL. This option might
also let me/help me name <something> if this is the first time I'm
fetching from a particular URL.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: use action dispatcher for non-project actions, too.
From: Jakub Narebski @ 2006-08-18 14:22 UTC (permalink / raw)
To: git
In-Reply-To: <87k656rvim.wl%cworth@cworth.org>
Carl Worth wrote:
> * A mechanism for not requiring me to invent tracking-branch names. I
> end up manually doing a scheme with short prefixes for any given
> repository. It would be nice if I could configure that (in
> .git/remotes/<something> say) once so that any new branch I pulled
> would get its properly named tracking branch. And git could find the
> right remotes file by matching up the URL.
This mechanism is called 'git clone --use-separate-remote'.
--use-separate-remote
Save remotes heads under $GIT_DIR/remotes/origin/ instead of
$GIT_DIR/refs/heads/. Only the master branch is saved in the latter.
(as origin).
(Shouldn't it be $GIT_DIT/refs/remotes/<repository>/ instead, BTW?)
And of course you can configure pull lines in the following way:
Pull: refs/heads/<branch>:refs/remotes/<repository>/<branch>
Unfortunately, there is no way to automatically pull new refs and tags
in such a way.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Unresolved issues #3
From: Nicolas Pitre @ 2006-08-18 14:49 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git
In-Reply-To: <44E546F2.7070902@gmail.com>
On Thu, 17 Aug 2006, A Large Angry SCM wrote:
> Junio C Hamano wrote:
> ...
> > * "A Large Angry SCM" wrote a nice summary, "Git files data
> > formats documentation".
> >
> > Message-ID: <44D51D47.9090700@gmail.com>
> >
> > With one final update by Nico yesterday, I think it is ready
> > for inclusion.
> >
> > Does somebody care to make a patch out of it to add it to
> > Documentation/technical/, maybe removing pack-format.txt there
> > after making sure all it talks about is covered by the new
> > documentation?
> >
> > I do not have enough "virginity" to spot omissions in the
> > description anymore, so comments from somebody new to the
> > system are very much appreciated.
> >
>
> Two things:
>
> 1) I disagree with Nico's assessment that, other than his, there can not
> exist any type 2 packs that have bit 6 set to mean copy from result.
Care to explain why?
Since this code is mine I can tell you that no official GIT version ever
produced such a pack. The code to make use of that bit was quite
involving and the end result wasn't great at all so I never published
said code. This is also why current GIT accepts both pack version 2 and
3 without any distinction using the same code in patch-delta.c on the
basis that no version 2 packs ever used that bit.
Nicolas
^ permalink raw reply
* Re: Unresolved issues #3
From: A Large Angry SCM @ 2006-08-18 14:56 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0608181041420.11359@localhost.localdomain>
Nicolas Pitre wrote:
> On Thu, 17 Aug 2006, A Large Angry SCM wrote:
...
>>
>> 1) I disagree with Nico's assessment that, other than his, there can not
>> exist any type 2 packs that have bit 6 set to mean copy from result.
>
> Care to explain why?
>
> Since this code is mine I can tell you that no official GIT version ever
^^^^^^^^^^^^^^^^^^^^^^^
> produced such a pack. The code to make use of that bit was quite
> involving and the end result wasn't great at all so I never published
> said code. This is also why current GIT accepts both pack version 2 and
> 3 without any distinction using the same code in patch-delta.c on the
> basis that no version 2 packs ever used that bit.
That doesn't prove the non-existence of other code to do it.
^ permalink raw reply
* Re: Unresolved issues #3
From: Nicolas Pitre @ 2006-08-18 15:30 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git
In-Reply-To: <44E5D522.8030407@gmail.com>
On Fri, 18 Aug 2006, A Large Angry SCM wrote:
> Nicolas Pitre wrote:
> > On Thu, 17 Aug 2006, A Large Angry SCM wrote:
> ...
> >>
> >> 1) I disagree with Nico's assessment that, other than his, there can not
> >> exist any type 2 packs that have bit 6 set to mean copy from result.
> >
> > Care to explain why?
> >
> > Since this code is mine I can tell you that no official GIT version ever
> ^^^^^^^^^^^^^^^^^^^^^^^
> > produced such a pack. The code to make use of that bit was quite
> > involving and the end result wasn't great at all so I never published
> > said code. This is also why current GIT accepts both pack version 2 and
> > 3 without any distinction using the same code in patch-delta.c on the
> > basis that no version 2 packs ever used that bit.
>
> That doesn't prove the non-existence of other code to do it.
So? If the official and primary code for GIT doesn't support it, what
is the point? I'm telling you that if such packs exist they will simply
barf with all official GIT releases later than v1.1.6 making your
argument pointless.
I don't mind you documenting that historic intent for a bit that was
never officially used, but at least let's document it right.
Nicolas
^ permalink raw reply
* Re: [PATCH] gitweb: use action dispatcher for non-project actions, too.
From: Petr Baudis @ 2006-08-18 15:40 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Martin Waitz, git
In-Reply-To: <87k656rvim.wl%cworth@cworth.org>
Dear diary, on Fri, Aug 18, 2006 at 04:03:29PM CEST, I got a letter
where Carl Worth <cworth@cworth.org> said that...
> * A single thingy I could publish for <URL> and <branch>. Ideally this
> would have no whitespace in it and would be directly
> cut-and-paste-able for use in either gitweb or the git command-line.
Perhaps you could paste a fetch URL to some gitweb inputbox at the top
of every page and it would show the right thing, sort of like mldonkey
with ed2k URLs...
> * A mechanism for not requiring me to invent tracking-branch names. I
> end up manually doing a scheme with short prefixes for any given
> repository. It would be nice if I could configure that (in
> .git/remotes/<something> say) once so that any new branch I pulled
> would get its properly named tracking branch. And git could find the
> right remotes file by matching up the URL.
We already have .git/refs/remote/ where the tracking branches are just
the same name as on the other side, we only need to start really using
it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* something broken just now on git-pull from openbsd to OSX
From: Randal L. Schwartz @ 2006-08-18 16:17 UTC (permalink / raw)
To: git
I just updated my openbsd's GIT to 1.4.2.g55c3, and now my
git-fetch from there to my OSX fails with a fatal error almost immediately.
What just changed? What can I check?
git-fetch from other repositories to OSX seems to work fine.
--
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.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: something broken just now on git-pull from openbsd to OSX
From: Randal L. Schwartz @ 2006-08-18 16:19 UTC (permalink / raw)
To: git
In-Reply-To: <86pseykogj.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> I just updated my openbsd's GIT to 1.4.2.g55c3, and now my
Randal> git-fetch from there to my OSX fails with a fatal error almost immediately.
Randal> What just changed? What can I check?
Randal> git-fetch from other repositories to OSX seems to work fine.
Ahh, it might even be a corrupt repository... here's what
a local git-clone shows:
git-clone ~/Git/stonehenge.git
remote: Generating pack...
remote: Done counting 2610 objects.
remote: Deltifying 2610 objects.
100% (2610/2610) done
remote: Total 2610, written 2610 (delta 1244), reused 2610 (delta 1244)
error: git-fetch-pack: unable to read from git-index-pack
error: git-index-pack died of signal 11
fetch-pack from '/home/merlyn/Git/stonehenge.git/.git' failed.
What do you want me to try to help diagnose this?
--
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.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Nicolas Pitre @ 2006-08-18 16:25 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn Pearce, git
In-Reply-To: <9e4733910608180615q4895334bw57c55e59a4ac5482@mail.gmail.com>
On Fri, 18 Aug 2006, Jon Smirl wrote:
> On 8/18/06, Nicolas Pitre <nico@cam.org> wrote:
> > A better way to get such a size saving is to increase the window and
> > depth parameters. For example, a window of 20 and depth of 20 can
> > usually provide a pack size saving greater than 11% with none of the
> > disadvantages mentioned above.
>
> Our window size is effectively infinite. I am handing him all of the
> revisions from a single file in optimal order. This includes branches.
In GIT packing terms this is infinite delta _depth_ not _window_.
> He takes these revisions, runs xdiff on them, and then puts the entire
> result into a single zlib blob.
This is not a good idea to have infinite delta depth. The time to
browse the repository history then becomes exponential with the number
of revisions making the value of such a repository a bit questionnable
(you could as well only preserve the last 2 years of history instead
since further than that with infinite delta depth is likely to be too
slow and painful to use).
But just for comparison I did a repack -a -f on the kernel repository
with --window=50 --depth=5000 which should be a good approximation of
the best possible delta matchingwith infinite depth.
Default delta params (window=10 depth=10) : 122103455
Agressive deltas (window=50 depth=5000) : 105870516
Reduction : 13%
OK let's try it with delta chains in the same zlib stream using the
patch I posted yesterday (with a minor tweak allowing the usage of -f
with git-repack).
Agressive and grouped deltas (window=50 depth=5000 : 99860685
This is a mere 5.7% reduction over the non grouped deltas, less than the
11% reduction I obtained yesterday when the delta depth is kept
reasonably short.
The increased delta depth is likely to make a large difference on old
repos with long history, maybe more so and with much less
complexity than the delta grouping.
> I suspect the size reduction is directly proportional to the age of
> the repository. The kernel repository only has three years worth of
> data in it. Linus has the full history in another repository that is
> not in general distribution. We can get it from him when he gets back
> from vacation.
>
> If the repository doesn't contain long delta chains the optimization
> doesn't help that much. On the other hand it doesn't hurt either since
> the chains weren't long. My repository is four times as old as the
> kernel one and I am getting 4x the benefit.
No that cannot be right.
Let's assume every whole objects are 10 in size and every deltas are 1.
You therefore can have 1 base object and 10 delta objects, effectively
storing 11 objects for a size of 20. You therefore have a 1.8 vs 10
size ratio.
If the delta depth is 100 then you potentially have 1 base object and
100 deltas for a size ratio of 1.1 vs 10.
If the delta depth is 1000 the ratiobecomes 1.01 vs 10.
The size saving is therefore _not_ proportional with the age of the
repository. It rather tend to be asymptotic with the delta ratio (but
impose an exponential runtime cost when fetching objects out of it).
The fact that your 4x old repository has
a 4x size saving
can be due only to packing malfunction I would say.
Nicolas
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Nicolas Pitre @ 2006-08-18 16:30 UTC (permalink / raw)
To: Jon Smirl; +Cc: Shawn Pearce, git
In-Reply-To: <9e4733910608180553r34fa7b25he0bf910ef804630f@mail.gmail.com>
On Fri, 18 Aug 2006, Jon Smirl wrote:
> I attached Shawn's code. He is gone until Monday and can't defend it.
I will have a look at it next week as I'll be gone for the weekend as
well.
> Do note that I am running this on the Mozilla CVS which is over 10
> years old. Some of the files have over 2,000 deltas. I average 10
> deltas per file but the distribution is not at all even. Many files
> get checked-in and never changed, for example 1000's of images.
This is IMHO more evidence that something is wrong with the results
you obtained.
Nicolas
^ permalink raw reply
* Re: Unresolved issues #3
From: Aneesh Kumar K.V @ 2006-08-18 16:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vpseyelcw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * Jeff Garzik reports that the summary page of gitweb does not
> look at anything other than "master" which is not appropriate
> for his tree.
>
> Message-ID: <44D874F0.6000907@garzik.org>
>
> I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,
> Aneesh) about this.
>
I just tried editing HEAD. For the project
http://git.openssi.org/~kvaneesh/gitweb.cgi?p=ci-to-linus.git;a=summary
$more HEAD
ref: refs/heads/from-linus
$
Is this solution fine ?. Or do we want to add a git-rep-config variable to indicate which branch to show.
-aneesh
^ permalink raw reply
* Re: Unresolved issues #3
From: Jakub Narebski @ 2006-08-18 16:48 UTC (permalink / raw)
To: git
In-Reply-To: <44E5ED82.8090904@gmail.com>
Aneesh Kumar K.V wrote:
> Junio C Hamano wrote:
>
>> * Jeff Garzik reports that the summary page of gitweb does not
>> look at anything other than "master" which is not appropriate
>> for his tree.
>>
>> Message-ID: <44D874F0.6000907@garzik.org>
>>
>> I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,
>> Aneesh) about this.
>
> I just tried editing HEAD. For the project
>
> http://git.openssi.org/~kvaneesh/gitweb.cgi?p=ci-to-linus.git;a=summary
>
> $more HEAD
> ref: refs/heads/from-linus
> $
>
> Is this solution fine ?. Or do we want to add a git-rep-config
> variable to indicate which branch to show.
Err, of course gitweb shows "Last Change" for HEAD, which usually is master.
The solution would be to show "Last Change" date to be the date of last
change of all/any branch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Huge win, compressing a window of delta runs as a unit
From: Jon Smirl @ 2006-08-18 16:56 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.64.0608181226460.11359@localhost.localdomain>
On 8/18/06, Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 18 Aug 2006, Jon Smirl wrote:
>
> > I attached Shawn's code. He is gone until Monday and can't defend it.
>
> I will have a look at it next week as I'll be gone for the weekend as
> well.
I looked at it some and couldn't see anything obviously wrong with it,
but it wasn't a detailed inspection.
As comparison, I just tar/zipped the Mozilla CVS repo and it is 541MB.
The 295MB git pack number does not have commits and trees in it, it is
revisions only.
It is not impossible that when the trees and commits are added to the
295MB number that it won't end up being near the 541MB number. We
already know xdiff is better at generating diffs than CVS diff. And I
still have to add 250K log entries and trees. Those are going to add
at least 100MB.
I will get back to work on the import code over the weekend. One of my
2 year olds gave me a cold so I have been useless the last couple of
days.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] make sha1_sort inline
From: David Rientjes @ 2006-08-18 16:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsljud2fs.fsf@assigned-by-dhcp.cox.net>
On Thu, 17 Aug 2006, Junio C Hamano wrote:
> The only use of this function is to got its address taken of,
> and then the variable that has its address (current_sort) is
> used by sort_comparator() function, whose address is given to
> the library routine qsort(3).
>
> Does it still make sense to declare it inline?
>
>
No.
Well, maybe just "not yet." The idea is to isolate the sort functions for
hashes since we may add support for additional ones in the future (re: my
thread on md5). Then all these functions would probably be abstracted to
a single file and labeled as static with a single global function:
static int hash_sort(const struct object_entry,
const struct object_entry);
which would call the static inline function that corresponds to the hash
in use for that database. This can't simply be #ifdef's since the choice
of hash would not be compile-time, it would be run-time depending on what
flags are sent during init-db.
And instead of:
struct object_entry {
unsigned char sha1[20];
...
}
it becomes:
struct object_entry {
union hash_name {
unsigned char sha1[20];
...
}
...
}
So in that case, the static inline of the sort does have its advantage as
opposed to two function calls on any hash_sort. But I agree in the
meantime while additional hashes are still be considered that this would
not be an advantageous addition to the code.
(At least you get an idea of what I'm thinking about hashes)
David
^ permalink raw reply
* Re: Unresolved issues #3
From: Aneesh Kumar K.V @ 2006-08-18 17:03 UTC (permalink / raw)
To: git
In-Reply-To: <ec4r0h$u9m$1@sea.gmane.org>
Jakub Narebski wrote:
> Aneesh Kumar K.V wrote:
>
>> Junio C Hamano wrote:
>>
>>> * Jeff Garzik reports that the summary page of gitweb does not
>>> look at anything other than "master" which is not appropriate
>>> for his tree.
>>>
>>> Message-ID: <44D874F0.6000907@garzik.org>
>>>
>>> I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,
>>> Aneesh) about this.
>> I just tried editing HEAD. For the project
>>
>> http://git.openssi.org/~kvaneesh/gitweb.cgi?p=ci-to-linus.git;a=summary
>>
>> $more HEAD
>> ref: refs/heads/from-linus
>> $
>>
>> Is this solution fine ?. Or do we want to add a git-rep-config
>> variable to indicate which branch to show.
>
> Err, of course gitweb shows "Last Change" for HEAD, which usually is master.
> The solution would be to show "Last Change" date to be the date of last
> change of all/any branch.
>
I didn't quiet understand that. AFAIU what jeff wanted is to make gitweb show some branch other than master
by default in the summary page. I guess editing HEAD enables that.
-aneesh
^ permalink raw reply
* Re: [PATCH] cleans up builtin-mv
From: David Rientjes @ 2006-08-18 17:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608181137000.28360@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 18 Aug 2006, Johannes Schindelin wrote:
> First, it _was_ a perl script, which you probably could find out by
> checking your old git.
>
> Second, it was rewritten to use Git.pm, and because _that_ did not work,
> git-mv was rewritten as a builtin.
>
It shouldn't have ever been a perl script, it should have been /bin/sh.
Any shell implementation of this would be significantly faster than the
current implementation.
> Not slower? I beg to differ, admitting it is only a few percent. But your
> statement is obviously uncorrect.
>
It _is_ slower since it takes considerably more time to do its job than
any corresponding shell script.
> Well, the patch has an improvement factor of almost none. I actually read
> the patch, and asked myself: why would anybody fix a non-problem?
>
Because it's _wrong_. Secondly, it's WRONG.
> > For example:
> > (length = strlen(source[i])) >= 0
>
> Yes. Taken out of context, this sure sounds silly.
>
> What you cleverly did not mention: It was inside a
>
> if (!bad &&
> (length = strlen(source[i])) >= 0 &&
> !strncmp(destination[i], source[i], length) &&
> (destination[i][length] == 0 || destination[i][length] == '/'))
>
> construct. So, we assign the "length" variable only if we have to. And the
> ">= 0" trick is a common one. I could have done
>
This is not a plausible justification _at all_. The idea that "length" is
assigned only on the condition that lstat(path, ...) failed does not
justify its comparison to >= 0 since this comparison is always true, nor
does it justify the assignment of
char *dir = source[i];
int len = strlen(dir);
later.
> > strlen(source[i]) was assigned to a variable later in the function, this
> > time called "len" instead.
>
> Only if source[i] is a directory. So again, we only do it when we need to.
>
You're completely ignoring the point, and more importantly, ignoring the
code path. Your implementation would have _always_ assigned
strlen(source[i]) to "length" if lstat returned 0. So at this point in
the code, "length" is always equal to strlen(source[i]). But your code
introduces another call to strlen, another variable, and another
assignment.
> Having said that, I do not have anything against the patch being applied,
> but if I see more of these i-would-like-the-cupboard-here-not-there
> patches, I will just not review them any more.
>
My patch is correct and improves your code. Any criticism for such a
patch has purely personal motives, and not technical motives, assigned to
it.
David
^ permalink raw reply
* Re: Unresolved issues #3
From: Jakub Narebski @ 2006-08-18 17:09 UTC (permalink / raw)
To: git
In-Reply-To: <ec4rsp$2vi$1@sea.gmane.org>
Aneesh Kumar K.V wrote:
> Jakub Narebski wrote:
>> Aneesh Kumar K.V wrote:
>>
>>> Junio C Hamano wrote:
>>>
>>>> * Jeff Garzik reports that the summary page of gitweb does not
>>>> look at anything other than "master" which is not appropriate
>>>> for his tree.
>>>>
>>>> Message-ID: <44D874F0.6000907@garzik.org>
>>>>
>>>> I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,
>>>> Aneesh) about this.
>>> I just tried editing HEAD. For the project
>>>
>>> http://git.openssi.org/~kvaneesh/gitweb.cgi?p=ci-to-linus.git;a=summary
>>>
>>> $more HEAD
>>> ref: refs/heads/from-linus
>>> $
>>>
>>> Is this solution fine ?. Or do we want to add a git-rep-config
>>> variable to indicate which branch to show.
>>
>> Err, of course gitweb shows "Last Change" for HEAD, which usually is
>> master. The solution would be to show "Last Change" date to be the date
>> of last change of all/any branch.
>
> I didn't quiet understand that. AFAIU what jeff wanted is to make
> gitweb show some branch other than master by default in the summary page.
> I guess editing HEAD enables that.
Editing head, well, having other branch checked out would be enough (checked
out before push would be enough I guess for gitweb repository being
"published repository", other that the copy you are working on).
AFAIR the problem was that development was not made at "master", so "Last
Changes" were last changes in master, no last changes as a whole. Last
changes date as a whole would be last change date of latest edited branch.
And for this I'd rather have functioning git-show-refs, for performance (at
least with larger number of heads...).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Why git-ls-tree has no --stdin option?
From: Junio C Hamano @ 2006-08-18 17:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ec45ca$id8$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Why git-ls-tree has no --stdin option to give <tree-ish> (feed it from
> git-ref-list for example), like git-diff-tree has? The output format could
> be similar: treeish, then git-ls-tree output, treeish, tree,...
The only reason is nobody felt need for it so far, hence nobody
bothered. If you find it useful, go wild.
> Also, is there a combination of options which would display only exact
> matches to path limit, i.e. tree entry only if path is directory, and file
> (blob) entry only if path is ordinary file?
I probably am misunderstanding the question but an empty set is
the combination you want perhaps?
$ git ls-tree HEAD -- t Document sha1 sha1_name.c
100644 blob e9eb6ce882ea92523c9a871c7581457af2dc78c5 sha1_name.c
040000 tree 3fb2bfdfef59e4ed10f525ef10ad8b43b8bc459e t
^ permalink raw reply
* Re: Why git-ls-tree has no --stdin option?
From: Jakub Narebski @ 2006-08-18 17:44 UTC (permalink / raw)
To: git
In-Reply-To: <7v7j16aqpv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>> Also, is there a combination of options which would display only exact
>> matches to path limit, i.e. tree entry only if path is directory, and file
>> (blob) entry only if path is ordinary file?
>
> I probably am misunderstanding the question but an empty set is
> the combination you want perhaps?
>
> $ git ls-tree HEAD -- t Document sha1 sha1_name.c
> 100644 blob e9eb6ce882ea92523c9a871c7581457af2dc78c5 sha1_name.c
> 040000 tree 3fb2bfdfef59e4ed10f525ef10ad8b43b8bc459e t
Yes, thank you very much.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Standard cogito + patches: Changes to 'master'
From: nico-linux-git @ 2006-08-18 17:54 UTC (permalink / raw)
To: git, nico-linux-git, pasky
Documentation/hooks.txt | 25 +++++++++++++++++++++++++
HOOKS | 12 ------------
cg-Xlib | 19 +++++++++++++++----
3 files changed, 40 insertions(+), 16 deletions(-)
New commits:
commit fbf2f2d95e1e6994d1604504d4edee453e563454
Author: Nico Schottelius <nico@hydrogenium.schottelius.org>
Date: Fri Aug 18 19:46:56 2006 +0200
Commit the running posix compatible showdate version (date is still
broken, but bashism is out)
commit da88c243c39abacbe0d19d65c388fc936a3ca89c
Author: Nico Schottelius <nico@hydrogenium.schottelius.org>
Date: Fri Aug 18 18:51:38 2006 +0200
Correct calculation, just very less slower than bashism variant
commit f04fb7a8673fa16593433e630ca0005233f01a25
Author: Nico Schottelius <nico@hydrogenium.schottelius.org>
Date: Fri Aug 18 18:02:31 2006 +0200
showdate with posix compatible expansion, test1
commit dee5043515eebecd11951001d65001c2b308d606
Author: Nico Schottelius <nico@hydrogenium.schottelius.org>
Date: Fri Aug 18 17:37:43 2006 +0200
showdate with sed+bc, testing
commit dae59abc62b8fa8c8246f5c4833cfae7edfad11b
Author: Nico Schottelius <nico@hydrogenium.schottelius.org>
Date: Fri Aug 18 17:37:13 2006 +0200
showdate with sed, testing
commit f4c17ba39056abeb5a995b375866c1220885d2ad
Author: Nico Schottelius <nico@hydrogenium.schottelius.org>
Date: Fri Aug 18 17:22:58 2006 +0200
Begin to remove bashism from showdate
commit 5283df5cca519921edca1b30402f9e6010f6404a
Author: Nico Schottelius <nico@hydrogenium.schottelius.org>
Date: Mon Jul 31 13:33:24 2006 +0200
Doc:hooks: Added information about "update"
commit f30eeb8b476d0d09d2b1b6012ff62d008bcaabfe
Author: Nico Schottelius <nico@hydrogenium.schottelius.org>
Date: Mon Jul 31 13:27:02 2006 +0200
Move hooks to Documentation subdirectory
^ permalink raw reply
* Re: Standard cogito + patches: Changes to 'master'
From: Nico -telmich- Schottelius @ 2006-08-18 18:01 UTC (permalink / raw)
To: git
In-Reply-To: <20060818175454.8961.qmail@bruehe.schottelius.org>
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
nico-linux-git@schottelius.org [Fri, Aug 18, 2006 at 05:54:54PM -0000]:
> [Commits]
For those who do not know where to find that branch:
Gitweb: http://unix.schottelius.org/cgi-bin/gitweb.cgi
Git-repo:http://unix.schottelius.org/git/cogito-original.git/
Nico
--
``...if there's one thing about Linux users, they're do-ers, not whiners.''
(A quotation of Andy Patrizio I completely agree with)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ 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