* Re: git cherry-pick before archive
From: Johannes Schindelin @ 2008-07-11 15:51 UTC (permalink / raw)
To: Denis Bueno; +Cc: Git Mailing List
In-Reply-To: <6dbd4d000807110846m2921ddb9r88eb3986762b8f81@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
> I'm trying to use git archive to create a kind of "release" tarball of
> my source. I've got a patch (a commit) that I'd like to apply to the
> tree before I call git archive on HEAD. Currently my command is:
>
> git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
>
> If I were to actually modify my tree & history, I'd change the command to:
>
> git cherry-pick 97a1235ce674f7cf4df3129cd0ab1ae0793db392
> git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
> git reset --hard HEAD^
>
> But I'd rather not modify my history, if it's possible. (This will
> create a bunch of dangling commit objects over time, no?)
$ git cherry-pick -n <bla>
$ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
$ git reset
Hth,
Dscho
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Steffen Prohaska @ 2008-07-11 15:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Junio C Hamano, msysGit, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807111349470.3640@eeepc-johanness>
On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:
> On Fri, 11 Jul 2008, Steffen Prohaska wrote:
>
>> I decided to stop queuing changes in 4msysgit. Instead I'd like to
>> bring the diff between Junio's and 4msysgit's master to zero. This
>> seems to be achievable after Junio merged Hannes' MinGW changes.
>>
>> I think all Windows-related changes to the git code base could be
>> discussed directly on the main git list and the msysgit list would be
>> reserved for the MinGW/MSYS runtime environment and the installer.
>
> I disagree. Judging from the mails I read on the git list, Junio gets
> really swamped by patches these days (what with our very productive
> GSoC
> students).
Sending the patches to the git list does not necessarily mean that
they are directly addressed to Junio. We discuss JGIT, EGIT, gitk,
and git gui patches on the list too. AFAIK, none of them are applied
by Junio directly but by the respective maintainers. We could handle
Windows-related patches similarly.
> I really think that we should discuss the patches on the msysGit list
> first, whip them into shape, and then send them off.
>
> Just think of those patches that were sent off, only to realize that
> they
> were no longer needed. That should not have happened.
I intentionally sent the patches to show and discuss the differences
between the state of the MinGW port in Junio's master and in 4msysgit.
Some of the patches could be reverted in 4msysgit. But, at least one
patch was unrelated to MinGW and is now in master. Some other patches
need more work and are currently improved. I think this was not a waste
of time.
Steffen
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Johannes Schindelin @ 2008-07-11 15:48 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <7f9d599f0807110841r329dfb95g786a576bd981dd1b@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Geoffrey Irving wrote:
> On Fri, Jul 11, 2008 at 8:36 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > Why so complicated? I mean, you can count in that "infinite" loop
> > yourself, no?
>
> Yeah, I was just trying to avoid the extra termination condition,
> because I don't think it adds any real safety.
Sorry. You absolutely lost me. While doing the loop over the entries,
trying to find an entry, adding a counter, and exiting when the counter
reaches the total number of slots does not add any real safety?
Puzzled,
Dscho
^ permalink raw reply
* git cherry-pick before archive
From: Denis Bueno @ 2008-07-11 15:46 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I'm trying to use git archive to create a kind of "release" tarball of
my source. I've got a patch (a commit) that I'd like to apply to the
tree before I call git archive on HEAD. Currently my command is:
git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
If I were to actually modify my tree & history, I'd change the command to:
git cherry-pick 97a1235ce674f7cf4df3129cd0ab1ae0793db392
git archive --format=tar --prefix=pfx/ HEAD | gzip > prj.tgz
git reset --hard HEAD^
But I'd rather not modify my history, if it's possible. (This will
create a bunch of dangling commit objects over time, no?)
--
Denis
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Geoffrey Irving @ 2008-07-11 15:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0807111635400.8950@racer>
On Fri, Jul 11, 2008 at 8:36 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 11 Jul 2008, Geoffrey Irving wrote:
>
>> On Thu, Jul 10, 2008 at 11:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> > "Geoffrey Irving" <irving@naml.us> writes:
>> >
>> >>>> Oops: avoiding the infinite loop only requires reading expected O(1)
>> >>>> entries on load, so I can fix that if you like. It would only be all of
>> >>>> them if it actually did detect the infinite loop.
>> >>>
>> >>> I have to admit that you lost me there. AFAIR the patch-id cache is a
>> >>> simple commit->patch_id store, right? Then there should be no way to get
>> >>> an infinite loop.
>> >>
>> >> If every entry is nonnull, find_helper loops forever.
>> >
>> > Isn't it sufficient to make this part check the condition as well?
>> >
>> > + if (cache->count >= cache->size)
>> > + {
>> > + warning("%s is corrupt: count %"PRIu32" >= size %"PRIu32,
>> > + filename, cache->count, cache->size);
>> > + goto empty;
>> > + }
>> >
>> > At runtime you keep the invariants that hashtable always has at most 3/4
>> > full and whoever wrote the file you are reading must have honored that as
>> > well, or there is something fishy going on.
>>
>> Good point. There's no reason not to check the 3/4 condition. It isn't
>> sufficient to avoid the infinite loop, though, since we don't verify
>> that count is accurate.
>
> Why so complicated? I mean, you can count in that "infinite" loop
> yourself, no?
Yeah, I was just trying to avoid the extra termination condition,
because I don't think it adds any real safety.
Geoffrey
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Johannes Schindelin @ 2008-07-11 15:36 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <7f9d599f0807110758y6c4ea7bepd726daf4fe5f074c@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Geoffrey Irving wrote:
> On Thu, Jul 10, 2008 at 11:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > "Geoffrey Irving" <irving@naml.us> writes:
> >
> >>>> Oops: avoiding the infinite loop only requires reading expected O(1)
> >>>> entries on load, so I can fix that if you like. It would only be all of
> >>>> them if it actually did detect the infinite loop.
> >>>
> >>> I have to admit that you lost me there. AFAIR the patch-id cache is a
> >>> simple commit->patch_id store, right? Then there should be no way to get
> >>> an infinite loop.
> >>
> >> If every entry is nonnull, find_helper loops forever.
> >
> > Isn't it sufficient to make this part check the condition as well?
> >
> > + if (cache->count >= cache->size)
> > + {
> > + warning("%s is corrupt: count %"PRIu32" >= size %"PRIu32,
> > + filename, cache->count, cache->size);
> > + goto empty;
> > + }
> >
> > At runtime you keep the invariants that hashtable always has at most 3/4
> > full and whoever wrote the file you are reading must have honored that as
> > well, or there is something fishy going on.
>
> Good point. There's no reason not to check the 3/4 condition. It isn't
> sufficient to avoid the infinite loop, though, since we don't verify
> that count is accurate.
Why so complicated? I mean, you can count in that "infinite" loop
yourself, no?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix backwards-incompatible handling of core.sharedRepository
From: Petr Baudis @ 2008-07-11 15:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6a1kmpq.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 10, 2008 at 10:34:57PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Petr Baudis <pasky@suse.cz> writes:
> >
> >> The 06cbe8550324e0fd2290839bf3b9a92aa53b70ab core.sharedRepository
> >> handling extension broke backwards compatibility; before, shared=1 meant
> >> that Git merely ensured the repository is group-writable, not that it's
> >> _only_ group-writable, which is the current behaviour.
> >
> > Donn't our existing tests catch this, and if the answer is no because we
> > don't have any, could you add some?
(Will do. Wanted to do it but forgot. :-)
> >> diff --git a/path.c b/path.c
> >> index 5983255..75c5915 100644
> >> --- a/path.c
> >> +++ b/path.c
> >> @@ -269,7 +269,7 @@ int adjust_shared_perm(const char *path)
> >> mode = st.st_mode;
> >>
> >> if (shared_repository) {
> >> - int tweak = shared_repository;
> >> + int tweak = (mode & 0777) | shared_repository;
> >> if (!(mode & S_IWUSR))
> >> tweak &= ~0222;
> >> mode = (mode & ~0777) | tweak;
> >
> > I think this change is good. shared_repository has always been about
> > widening the access and not about limiting.
>
> Having said that, you really should protect this behaviour from regression
> with a test case. I do not see practical difference for sane umask
> values.
>
> What umask are you using, and which file in the repository gets affected?
> In the old code I see we do have checks for S_IXUSR and tweaks on S_IXGRP
> and S_IXOTH, but this should make a difference only if your umask blocks
> executable bit and the file in question is executable. Was it an
> executable hook copied from template?
My umask is 002, and the difference is visible at all the files in the
repository (in existing repositories, update will cause new object files
have the missing permission, making for the most confusing behaviour).
With sane Git versions, the permissions when shared=1 are rwxrwxr-x,
with recent Git however, it is rwxrwx--- (modulo the exec bits).
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Toralf Förster @ 2008-07-11 14:58 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Johannes Schindelin, git
In-Reply-To: <37fcd2780807110744k3b2a332csdf788dabd172622c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
At Friday 11 July 2008 16:44:23 Dmitry Potapov wrote :
> On Fri, Jul 11, 2008 at 5:39 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
> >
> > Ok, following the thread I understand why this feature isn't wanted by all. But
> > for the given example (where I only pulled from another git tree) this could
> > work, isn't it : ?
> >
> > tfoerste@n22 ~/devel/linux-2.6 $ git-log v2.6.26-rc9.. | perl -e '@c = grep { /^commit/ } <>; print map { $#c - $i++ . "\t" . $_ } @c'
>
> No, it does not. Running your script, I have
>
> ...
> 56 commit 803a9067e19714ea7b7da760fe92f0d53bfa6994
> ...
>
> Now, let's see what git-describe thinks about it
> $ git describe 803a9067e19714ea7b7da760fe92f0d53bfa6994
> v2.6.26-rc9-38-g803a906
>
> Your script is obviously incorrect. It is written in the assumption that
> history is linear, but it is not. Even if you pull only from one repo,
> this repo still contains *many* branches. Along any branch, you may have
> the same number.
>
> Dmitry
>
Yes,
$> git-log v2.6.26-rc9.. --pretty=short | grep "^commit" | cut -f2 -d' ' | xargs -n 1 git describe | grep '\-56\-'
I used eventually to get the commit id for the (broken) UML kernel 2.6.26-rc9-56
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Geoffrey Irving @ 2008-07-11 14:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git@vger.kernel.org
In-Reply-To: <7v3amglxmb.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 10, 2008 at 11:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Geoffrey Irving" <irving@naml.us> writes:
>
>>>> Oops: avoiding the infinite loop only requires reading expected O(1)
>>>> entries on load, so I can fix that if you like. It would only be all of
>>>> them if it actually did detect the infinite loop.
>>>
>>> I have to admit that you lost me there. AFAIR the patch-id cache is a
>>> simple commit->patch_id store, right? Then there should be no way to get
>>> an infinite loop.
>>
>> If every entry is nonnull, find_helper loops forever.
>
> Isn't it sufficient to make this part check the condition as well?
>
> + if (cache->count >= cache->size)
> + {
> + warning("%s is corrupt: count %"PRIu32" >= size %"PRIu32,
> + filename, cache->count, cache->size);
> + goto empty;
> + }
>
> At runtime you keep the invariants that hashtable always has at most 3/4
> full and whoever wrote the file you are reading must have honored that as
> well, or there is something fishy going on.
Good point. There's no reason not to check the 3/4 condition. It
isn't sufficient to avoid the infinite loop, though, since we don't
verify that count is accurate.
Another route would to eliminate the count field entirely, and replace
the count >= size/4*3 check with a statistical one based on the
entries seen so far. The main advantage of that would be to make
incremental writes simpler by avoiding the need to update the header.
The disadvantage is that there would be a small chance that the map
would grow in size despite being almost empty. Thoughts on whether we
should do that?
>>> Besides, this is a purely local cache, no? Never to be transmitted... So
>>> not much chance of a malicious attack, except if you allow write access to
>>> your local repository, in which case you are endangered no matter what.
>>
>> Yep, that's why it's only a hole in quotes, and why I didn't fix it.
>
> You might want to protect yourself against file corruption, though.
> Checksumming the whole file and checking it at opening defeats the point
> of mmap'ed access, but at least the header may want to be checksummed?
Okay. I imagine I should use sha1 as the sum?
Geoffrey
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Toralf Förster @ 2008-07-11 14:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807111533310.8950@racer>
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
At Friday 11 July 2008 16:36:07 Johannes Schindelin wrote :
> The question is not so much if it would work, but what people would do
> with this. They would probably include something in a mail to you like
> "v2.6.26-rc9-111 stopped working!", you would test "v2.6.26-rc9-111" and
> go back "but it still works!".
>
> Because you are talking about two different things.
>
> So, in what workflow would v2.6.26-rc9-111 actually be helpful? For
> yourself working in your own lil' branch? I do not think so. HEAD~23 is
> much more helpful in that case, since locally, you do not work so much
> relative to a given tag, but relative to your current HEAD.
>
> Hth,
> Dscho
Ah yes, this clarified it for me.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Dmitry Potapov @ 2008-07-11 14:44 UTC (permalink / raw)
To: Toralf Förster; +Cc: Johannes Schindelin, git
In-Reply-To: <200807111539.06606.toralf.foerster@gmx.de>
On Fri, Jul 11, 2008 at 5:39 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
>
> Ok, following the thread I understand why this feature isn't wanted by all. But
> for the given example (where I only pulled from another git tree) this could
> work, isn't it : ?
>
> tfoerste@n22 ~/devel/linux-2.6 $ git-log v2.6.26-rc9.. | perl -e '@c = grep { /^commit/ } <>; print map { $#c - $i++ . "\t" . $_ } @c'
No, it does not. Running your script, I have
...
56 commit 803a9067e19714ea7b7da760fe92f0d53bfa6994
...
Now, let's see what git-describe thinks about it
$ git describe 803a9067e19714ea7b7da760fe92f0d53bfa6994
v2.6.26-rc9-38-g803a906
Your script is obviously incorrect. It is written in the assumption that
history is linear, but it is not. Even if you pull only from one repo,
this repo still contains *many* branches. Along any branch, you may have
the same number.
Dmitry
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Johannes Schindelin @ 2008-07-11 14:36 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <200807111539.06606.toralf.foerster@gmx.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1356 bytes --]
Hi,
On Fri, 11 Jul 2008, Toralf Förster wrote:
> At Thursday 10 July 2008 21:29:07 Johannes Schindelin wrote :
>
> > On Thu, 10 Jul 2008, Toralf Förster wrote:
> >
> > > I appended those strings to the names of my UML kernel executables.
> > > Unfortunately I didn't used the commit id and now I'm wondering
> > > whether git could accept v2.6.26-rc9-56 as well in future.
> >
> > If that were unambiguous, yes. But it is not.
>
> Ok, following the thread I understand why this feature isn't wanted by
> all. But for the given example (where I only pulled from another git
> tree) this could work, isn't it : ?
>
> tfoerste@n22 ~/devel/linux-2.6 $ git-log v2.6.26-rc9.. | perl -e '@c = grep { /^commit/ } <>; print map { $#c - $i++ . "\t" . $_ } @c'
The question is not so much if it would work, but what people would do
with this. They would probably include something in a mail to you like
"v2.6.26-rc9-111 stopped working!", you would test "v2.6.26-rc9-111" and
go back "but it still works!".
Because you are talking about two different things.
So, in what workflow would v2.6.26-rc9-111 actually be helpful? For
yourself working in your own lil' branch? I do not think so. HEAD~23 is
much more helpful in that case, since locally, you do not work so much
relative to a given tag, but relative to your current HEAD.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 0/3] Git::Repo API and gitweb caching
From: Lea Wiemann @ 2008-07-11 14:07 UTC (permalink / raw)
To: Jakub Narebski
Cc: Git Mailing List, John Hawley, Petr Baudis, Johannes Schindelin
In-Reply-To: <200807111133.11662.jnareb@gmail.com>
Jakub Narebski wrote:
> On Fri, 11 July 2008, Lea Wiemann wrote:
>> 1) adding the Mechanize tests,
>
> Somehow I didn't get Cc-ed this patch...
Yup, nobody got Cc'ed; apologies.
> If I remember correctly Mechanize tests detected some bugs in gitweb
> (nice!), but there were swept under the rug, i.e. put as TODO.
>
> Does that mean that those errors were corrected, or that refactoring
> "just" didn't break anything more?
Refactoring really just didn't break anything more; it could be that
something got corrected accidentally, but I'd be surprised.
>> - Benchmarks.
>
> Do you plan to compare other gitweb caching implementations? [k.org, repo.or.cz]
Yup, sure.
>> - Implementing support for Last-Modified or ETags [...] will require
>> mod_perl, since CGI doesn't allow for accessing arbitrary request headers
>
> $requested_language = http('Accept-language');
>
> the header lines received from the client, if any, are placed into the
> environment with the prefix HTTP_ followed by the header name.
Right, you'd think the request headers should be accessible this way,
but apparently not all of them are.
If you take this script, ...
#!/usr/bin/perl
use CGI qw(http);
print "Content-type: text/plain\n";
print "Last-Modified: Thu, 03 Jul 2008 22:39:42 GMT\n\n";
print "Header: ", http('If-Last-Modified');
... then my browser (according to LiveHTTPHeaders) sends an
If-Last-Modified header, but it doesn't get through to the CGI script.
It does work if you test Accept-Language. (Try print `env` to get an
idea of what gets through.) It happens on Apache and thttpd.
Apparently this part somehow applies:
> 'The server may exclude any headers which it has already processed,'
I honestly have no idea why the If-Last-Modified headers gets eaten (and
googling didn't help), but I assume that at least it'll be possible to
access all headers with mod_perl.
> 'If-Not-Modified-Since', 'If-Match' (by caches)
Wait, are you sure caches would use those headers (I believe only the
latter actually exists BTW), or did you fall prey to a thinko? ;)
> one "shortcut" is that gitweb respects HEAD request
> (returning only HTTP headers) for feeds
Yes, and I think it does help performance-wise, but only a really small
fraction of the RSS/Atom requests actually use HEAD. Most use GET.
> I think that ls_tree and git-ls-tree output parsing should be
> generalized into Git::Tree API as well.
True, though I'm still not sure how to make element access work pretty
and fast. I'll keep pondering it for a while.
> I'll try to review the rest of patches by tomorrow...
Thanks!
Johannes Schindelin wrote:
> FWIW there are a few reasons why splitting up (3) might be the thing
> you really want to do
I've put splitting it on my list; I'm not sure though if I'll get around
to doing it today. Everyone, comments on patch (3) are still
appreciated in the meantime. ;-) I'll integrate any suggestions/patches
when I split it up.
-- Lea
^ permalink raw reply
* Re: git pull is slow
From: Johannes Schindelin @ 2008-07-11 14:04 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Stephan Hennig, git
In-Reply-To: <48776169.20705@op5.se>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1923 bytes --]
Hi,
On Fri, 11 Jul 2008, Andreas Ericsson wrote:
> Stephan Hennig wrote:
> > Stephan Hennig schrieb:
> >
> > > I am observing very large data transfers when pulling from the
> > > repository at <URL:http://repo.or.cz/w/wortliste.git>.
> >
> > Here's the output of a recent pull:
> >
> > > unknown@COMMODORE ~/Themen/trennmuster/repository/wortliste (master)
> > > $ git pull
> > > Enter passphrase for key '/x/home/.ssh/id_rsa':
> > > remote: Counting objects: 15, done.←[K
> > > remote: Compressing objects: 100% (7/7), done.←[K) ←[Kts: 8% (1/12)
> > > remote: Total 12 (delta 5), reused 12 (delta 5)←[K
> > > Unpacking objects: 100% (12/12), done.
> > > From git+ssh://xxx@repo.or.cz/srv/git/wortliste
> > > d905095..d0c6a33 master -> origin/master
> > > * [new tag] dehyph-exptl-v0.13 -> dehyph-exptl-v0.13
> > > Updating d905095..d0c6a33
> > > Fast forward
> > > wortliste←[m | 19 ←[32m+++++++++++←[m←[31m--------←[m
> > > 1 files changed, 11 insertions(+), 8 deletions(-)←[m
> >
> > After the line containing "remote: Compressing objects:" had been
> > printed several MB have been transferred.
> >
>
> Seems like you're being bitten by a bug we had some months back,
> where the client requested full history for new tag objects.
I do not think so. I think it is a problem with the pack. The slowness
is already there in the clone, in the resolving phase.
Judging from the output of "verify-pack -v", it seems that the delta
chains are quite long.
I saw memory usage go up pretty quickly. I thought that maybe
eac12e2(Correct pack memory leak causing git gc to try to exceed ulimit)
would help things, since it fixes a place where memory usage grows out of
bounds, but it did not.
Unfortunately, I do not have time to look into this further.
BTW there is a nasty usability bug when "Compressing objects:" and
"Receiving objects:" messages
Ciao,
Dscho
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Toralf Förster @ 2008-07-11 13:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807102028420.18205@racer>
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
At Thursday 10 July 2008 21:29:07 Johannes Schindelin wrote :
> Hi,
>
> On Thu, 10 Jul 2008, Toralf Förster wrote:
>
> > I appended those strings to the names of my UML kernel executables.
> > Unfortunately I didn't used the commit id and now I'm wondering whether
> > git could accept v2.6.26-rc9-56 as well in future.
>
> If that were unambiguous, yes. But it is not.
>
> Ciao,
> Dscho
>
Ok, following the thread I understand why this feature isn't wanted by all. But
for the given example (where I only pulled from another git tree) this could
work, isn't it : ?
tfoerste@n22 ~/devel/linux-2.6 $ git-log v2.6.26-rc9.. | perl -e '@c = grep { /^commit/ } <>; print map { $#c - $i++ . "\t" . $_ } @c'
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git pull is slow
From: Andreas Ericsson @ 2008-07-11 13:34 UTC (permalink / raw)
To: Stephan Hennig; +Cc: git
In-Reply-To: <g57jkp$ekm$1@ger.gmane.org>
Stephan Hennig wrote:
> Stephan Hennig schrieb:
>
>> I am observing very large data transfers when pulling from the
>> repository at <URL:http://repo.or.cz/w/wortliste.git>.
>
> Here's the output of a recent pull:
>
>> unknown@COMMODORE ~/Themen/trennmuster/repository/wortliste (master)
>> $ git pull
>> Enter passphrase for key '/x/home/.ssh/id_rsa':
>> remote: Counting objects: 15, done.←[K
>> remote: Compressing objects: 100% (7/7), done.←[K) ←[Kts: 8% (1/12)
>> remote: Total 12 (delta 5), reused 12 (delta 5)←[K
>> Unpacking objects: 100% (12/12), done.
>> From git+ssh://xxx@repo.or.cz/srv/git/wortliste
>> d905095..d0c6a33 master -> origin/master
>> * [new tag] dehyph-exptl-v0.13 -> dehyph-exptl-v0.13
>> Updating d905095..d0c6a33
>> Fast forward
>> wortliste←[m | 19 ←[32m+++++++++++←[m←[31m--------←[m
>> 1 files changed, 11 insertions(+), 8 deletions(-)←[m
>
> After the line containing "remote: Compressing objects:" had been
> printed several MB have been transferred.
>
Seems like you're being bitten by a bug we had some months back,
where the client requested full history for new tag objects.
Does this bug still show up if you use the latest git from
master of git.git?
I *think* v1.5.4.3-440-g41fa7d2 fixed the issue, but I'm
not 100% certain as the commit message doesn't mention anything
about any bugs being solved. Otoh, I vaguely remember the first
bug-reporter being told to try 'next', and afair, that solved it
for him/her.
> Does it matter that the original clone has been performed with plain git
> protocol? I have only later changed the url in .git/config to use git+ssh.
>
No, that doesn't matter in the slightest.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git pull is slow
From: Stephan Hennig @ 2008-07-11 12:55 UTC (permalink / raw)
To: git
In-Reply-To: <g5570s$d5m$1@ger.gmane.org>
Stephan Hennig schrieb:
> Does it matter that the original clone has been performed with plain git
> protocol? I have only later changed the url in .git/config to use git+ssh.
To be precise, the original pull has been done via
url = git://repo.or.cz/wortliste.git
which is a read-only URL. I changed .git/config manually to point to
url = git+ssh://xxx@repo.or.cz/srv/git/wortliste.git
later, which is the push URL.
Best regards,
Stephan Hennig
^ permalink raw reply
* Re: Ext4 patchqueue corrupted ?
From: Petr Baudis @ 2008-07-11 13:13 UTC (permalink / raw)
To: Theodore Tso
Cc: Aneesh Kumar K.V, Ming Ming Cao, linux-ext4@vger.kernel.org, git
In-Reply-To: <20080711124742.GA20099@mit.edu>
Hi,
On Fri, Jul 11, 2008 at 08:47:42AM -0400, Theodore Tso wrote:
> Can you completely zap the repository replace it with a freshly
> "git init"-ialized files, and I'll try repushing?
right, I have done that now. For anyone interested in the corrupted
repository, the backed up refs and objects directories are still in the
repository under the name *.broken, e.g. at
http://repo.or.cz/r/ext4-patch-queue.git
I will try to analyze it myself later.
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: Ext4 patchqueue corrupted ?
From: Theodore Tso @ 2008-07-11 12:47 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Petr Baudis, Ming Ming Cao, linux-ext4@vger.kernel.org, git
In-Reply-To: <20080711123109.GA14606@skywalker>
On Fri, Jul 11, 2008 at 06:01:09PM +0530, Aneesh Kumar K.V wrote:
> On Fri, Jul 11, 2008 at 08:26:17AM -0400, Theodore Tso wrote:
> > On Fri, Jul 11, 2008 at 10:47:15AM +0200, Petr Baudis wrote:
> > > very puzzling; I have backed up the broken objects store, can you
> > > repush, please? I'm curious about how this could have happenned;
> > > repo.or.cz now uses Git from latest next, which is a rather strange
> > > coincidence. ;-) Or did any of the pushers do anything special about
> > > pushin to the repository recently?
> >
> > Aneesh, did you try repushing? It looks like the objects store is
> > broken again.
>
> I don't have permission to push to the repo. I can only pull.
Right, sorry, I forgot that you didn't have write access to the repo.
Pasky, my attempt to push is failing:
<tytso@closure> {/usr/projects/linux/ext4/.git/patches/ext4dev} [master]
101% git push git+ssh://repo.or.cz/srv/git/ext4-patch-queue.git master:master
Everything up-to-date
error: refs/tags/v2.6.20-ext4-1 does not point to a valid object!
error: refs/tags/v2.6.20-rc5-ext4-1 does not point to a valid object!
<tytso@closure> {/usr/projects/linux/ext4/.git/patches/ext4dev} [master]
102% git push git+ssh://repo.or.cz/srv/git/ext4-patch-queue.git +refs/heads/*:refs/heads/*
error: refs/tags/v2.6.20-ext4-1 does not point to a valid object!
error: refs/tags/v2.6.20-rc5-ext4-1 does not point to a valid object!
Total 0 (delta 0), reused 0 (delta 0)
error: unpack should have generated a1a5e2eaaea5292da062f6dfbed66b5e07d396d3, but I can't find it!
error: unpack should have generated bd5803bec71c494ba3ac7b147fd4d0deed423a5b, but I can't find it!
To git+ssh://repo.or.cz/srv/git/ext4-patch-queue.git
! [remote rejected] 2.6.23-ext4-1 -> 2.6.23-ext4-1 (bad pack)
! [remote rejected] origin -> origin (bad pack)
error: failed to push some refs to 'git+ssh://repo.or.cz/srv/git/ext4-patch-queue.git'
And git ls-remote tells an even sadder tale:
<tytso@closure> {/usr/projects/linux/ext4/.git/patches/ext4dev} [master]
103% git ls-remote git+ssh://repo.or.cz/srv/git/ext4-patch-queue.git
error: missing object referenced by 'refs/tags/2.6.23-ext4-1'
error: missing object referenced by 'refs/tags/2.6.24-ext4-1'
error: missing object referenced by 'refs/tags/2.6.24-ext4-rc4-1'
error: missing object referenced by 'refs/tags/2.6.24-git12-ext4-1'
error: missing object referenced by 'refs/tags/2.6.24-git6-ext4-1'
error: missing object referenced by 'refs/tags/2.6.24-rc1-ext4-1'
error: missing object referenced by 'refs/tags/2.6.24-rc8-ext4-1'
error: missing object referenced by 'refs/tags/2.6.25-git15-ext4-1'
error: missing object referenced by 'refs/tags/2.6.25-rc4-ext4-1'
error: refs/tags/v2.6.20-ext4-1 does not point to a valid object!
error: refs/tags/v2.6.20-rc5-ext4-1 does not point to a valid object!
error: missing object referenced by 'refs/tags/v2.6.20-rc7-ext4-1'
error: missing object referenced by 'refs/tags/v2.6.21-ext4-1'
error: missing object referenced by 'refs/tags/v2.6.22-rc4-ext4-1'
error: missing object referenced by 'refs/tags/v2.6.26-rc2-ext4-1'
ec90e41198ede71d186bb7075e2edea7a6daae5a HEAD
ec90e41198ede71d186bb7075e2edea7a6daae5a refs/heads/master
346bfccb5d3af0ee5bda961d2e2fcbf1c9d71ef6 refs/tags/2.6.23-ext4-1
47f7b357a1468e42a5d16b9f12ceb9d5c0d1da5e refs/tags/2.6.24-ext4-1
558ca8d2472d43341f80627da9bef266a33e29c1 refs/tags/2.6.24-ext4-rc4-1
0f329cb9046106a0bc2ce1e8ba4a1d431e4761fe refs/tags/2.6.24-git12-ext4-1
fb4f7981226285b1cd9230bd584ad8c442441fd1 refs/tags/2.6.24-git6-ext4-1
04ccbce687206f51e8e2d243505381c0da48db2b refs/tags/2.6.24-rc1-ext4-1
058e44f59dc308408ac3558f7d375b1c55e429fe refs/tags/2.6.24-rc8-ext4-1
419fe473159404c4ce0a516e3d435705271de3d8 refs/tags/2.6.25-git15-ext4-1
fe39106438de15396a7083d11cbc1f1511006382 refs/tags/2.6.25-rc4-ext4-1
dfc7edaaea270f4182d748de59ef83d3b679c54b refs/tags/v2.6.20-rc7-ext4-1
fb7f3bc312359e429a7308bf0fcffeb920ab2efc refs/tags/v2.6.21-ext4-1
0db80f52ee3366cae5a0c3276be2f7de1674b09b refs/tags/v2.6.22-rc4-ext4-1
be15cbe06b269fcacb80b8d8484ec606f5788de1 refs/tags/v2.6.26-rc2-ext4-1
Can you completely zap the repository replace it with a freshly
"git init"-ialized files, and I'll try repushing?
Thanks!!
- Ted
^ permalink raw reply
* Re: Ext4 patchqueue corrupted ?
From: Aneesh Kumar K.V @ 2008-07-11 12:31 UTC (permalink / raw)
To: Theodore Tso; +Cc: Petr Baudis, Ming Ming Cao, linux-ext4@vger.kernel.org, git
In-Reply-To: <20080711122617.GA8154@mit.edu>
On Fri, Jul 11, 2008 at 08:26:17AM -0400, Theodore Tso wrote:
> On Fri, Jul 11, 2008 at 10:47:15AM +0200, Petr Baudis wrote:
> > very puzzling; I have backed up the broken objects store, can you
> > repush, please? I'm curious about how this could have happenned;
> > repo.or.cz now uses Git from latest next, which is a rather strange
> > coincidence. ;-) Or did any of the pushers do anything special about
> > pushin to the repository recently?
>
> Aneesh, did you try repushing? It looks like the objects store is
> broken again.
I don't have permission to push to the repo. I can only pull.
>
> Pasky, in case it helps, and for the benefit of Linux-ext4 folks, I
> have a copy of my repository (which I last pushed to repo.or.cz around
> noon US/Eastern yesterday) here:
>
> git://git.kernel.org/pub/scm/fs/ext2/ext4-patch-queue.git
>
> My most recent HEAD is ec90e411; if anyone has something more recent,
> they can send it to me via:
>
> git bundle create /tmp/to-send ec90e411
>
> ... and then e-mailing me as an attachment the resulting binary file
> in /tmp/to-send.
>
-aneesh
^ permalink raw reply
* Re: jgit (was: [PATCH 4/4] Add a method...)
From: Robin Rosenberg @ 2008-07-11 12:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn O. Pearce, git, Marek Zawirski
In-Reply-To: <487750E3.90303@op5.se>
fredagen den 11 juli 2008 14.24.03 skrev Andreas Ericsson:
> Sorry for butting in, but I'd appreciate if you kept adding 'jgit'
> to the subject so I can keep filtering these patches out. The volume
> on git@vger is high enough without having to follow off-shoots that
> are of no particular concern to me (although I certainly applaud the
> effort).
It was an accident. Honestly :)
-- robin
^ permalink raw reply
* Re: git pull is slow
From: Stephan Hennig @ 2008-07-11 12:25 UTC (permalink / raw)
To: git
In-Reply-To: <g5570s$d5m$1@ger.gmane.org>
Stephan Hennig schrieb:
> I am observing very large data transfers when pulling from the
> repository at <URL:http://repo.or.cz/w/wortliste.git>.
Here's the output of a recent pull:
> unknown@COMMODORE ~/Themen/trennmuster/repository/wortliste (master)
> $ git pull
> Enter passphrase for key '/x/home/.ssh/id_rsa':
> remote: Counting objects: 15, done.←[K
> remote: Compressing objects: 100% (7/7), done.←[K) ←[Kts: 8% (1/12)
> remote: Total 12 (delta 5), reused 12 (delta 5)←[K
> Unpacking objects: 100% (12/12), done.
> From git+ssh://xxx@repo.or.cz/srv/git/wortliste
> d905095..d0c6a33 master -> origin/master
> * [new tag] dehyph-exptl-v0.13 -> dehyph-exptl-v0.13
> Updating d905095..d0c6a33
> Fast forward
> wortliste←[m | 19 ←[32m+++++++++++←[m←[31m--------←[m
> 1 files changed, 11 insertions(+), 8 deletions(-)←[m
After the line containing "remote: Compressing objects:" had been
printed several MB have been transferred.
Does it matter that the original clone has been performed with plain git
protocol? I have only later changed the url in .git/config to use git+ssh.
Best regards,
Stephan Hennig
^ permalink raw reply
* Re: Ext4 patchqueue corrupted ?
From: Theodore Tso @ 2008-07-11 12:26 UTC (permalink / raw)
To: Petr Baudis
Cc: Aneesh Kumar K.V, Ming Ming Cao, linux-ext4@vger.kernel.org, git
In-Reply-To: <20080711084715.GT10151@machine.or.cz>
On Fri, Jul 11, 2008 at 10:47:15AM +0200, Petr Baudis wrote:
> very puzzling; I have backed up the broken objects store, can you
> repush, please? I'm curious about how this could have happenned;
> repo.or.cz now uses Git from latest next, which is a rather strange
> coincidence. ;-) Or did any of the pushers do anything special about
> pushin to the repository recently?
Aneesh, did you try repushing? It looks like the objects store is
broken again.
Pasky, in case it helps, and for the benefit of Linux-ext4 folks, I
have a copy of my repository (which I last pushed to repo.or.cz around
noon US/Eastern yesterday) here:
git://git.kernel.org/pub/scm/fs/ext2/ext4-patch-queue.git
My most recent HEAD is ec90e411; if anyone has something more recent,
they can send it to me via:
git bundle create /tmp/to-send ec90e411
... and then e-mailing me as an attachment the resulting binary file
in /tmp/to-send.
- Ted
^ permalink raw reply
* jgit (was: [PATCH 4/4] Add a method...)
From: Andreas Ericsson @ 2008-07-11 12:24 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git, Marek Zawirski
In-Reply-To: <1215769719-5238-1-git-send-email-robin.rosenberg@dewire.com>
Sorry for butting in, but I'd appreciate if you kept adding 'jgit'
to the subject so I can keep filtering these patches out. The volume
on git@vger is high enough without having to follow off-shoots that
are of no particular concern to me (although I certainly applaud the
effort).
Thanks
Robin Rosenberg wrote:
[ a patch for jgit ]
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-11 11:56 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, Junio C Hamano, msysGit, Git Mailing List
In-Reply-To: <DDFD7E3B-8401-4EA0-9BBA-C9D8E25998A3@zib.de>
Hi,
On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> I decided to stop queuing changes in 4msysgit. Instead I'd like to
> bring the diff between Junio's and 4msysgit's master to zero. This
> seems to be achievable after Junio merged Hannes' MinGW changes.
>
> I think all Windows-related changes to the git code base could be
> discussed directly on the main git list and the msysgit list would be
> reserved for the MinGW/MSYS runtime environment and the installer.
I disagree. Judging from the mails I read on the git list, Junio gets
really swamped by patches these days (what with our very productive GSoC
students).
I really think that we should discuss the patches on the msysGit list
first, whip them into shape, and then send them off.
Just think of those patches that were sent off, only to realize that they
were no longer needed. That should not have happened.
My 2p,
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